1.3.7 vs 1.2.13 DVBT/AVC .ts playback bug?

[lif]

Hello Sub and others!

First of all, Sub, great thanks that you have had time to develop a new version and with Multi-record support!

But right after upgrade I ran into major issue. I had 1.2.13 running on "server" and "clients". Server has HVR-1300 and server-client setup worked as a charm. On clients I disabled "use built in transport stream reader filter for .ts files". Disabling this, playback brought up Haali Media Splitter and this called AC3Filter for audio and CoreAVC decoder for video. PVRX2 internal ".ts" reader filter didn't allow to SKIP/FFWD during playback (or did it very strange and slow). So, using external .ts splitter worked perfect.

After upgrading 1.2.13 -> 1.3.7 on server and clients, no I am unable to playback any recordings, new ones nor old ones did with 1.2.13. PVRX2 opens file, plays back it about with speed of 1fps and no audio and time on status bar rolls on astronomically (played 1sek of recording equals about 30min in PVRX2 "time"). On system tray there is only AC3Filter icon, but its status shows that no input for filter is provided. Also no Haali icon... Ticking "use internal .ts filter" and unticking it produces exactly the same described situation! :-(

So, Sub, is usage of external .ts filter/splitter is now broken or what? Or does installation have written over some registry settings, so reinstalling Haali and CoreAVC could resolve my issues?

[sub]

As GB-PVR has continued to move towards more dependence on transport streams in recent releases I now need a lot more information about the transport stream. Unfortunately external readers like the Haali splitter are unable to provide me this information, so at this stage its unlikely support for external .ts splitters will return.

1.2.13 did have a problem that could cause a slow skip on some machines, but this was resolved in 1.3.7.

If you're having problems playing files, first try playing it an attaching the pvxr2.exe.;log and pvrx2.exe-native.log and I'll take a look. If that doesnt have enough clues, I'll get you to make a small example recording available so I can try playing it here.

[lif]

Hi Sub!

It is extremely sad that even with advanced configuration external .ts filters are not any more supported. May be some computers did have problems with .ts / Haali splitter, but for example my setup did work perfectly. After I saw that gbpvr .ts reader is still in very early development stage and couldn't play my recordings I spent tens of hours researching for supporting filters and codecs combination to have a smooth setup, but now... I guess that I have to roll back to 1.2.13 if we can't find combination how to get it working ok.

BTW. If I playback recordings with 1.3.7 on my IBM T42, it utilises extremely more CPU time than 1.2.13 with Haali splitter :-( 1.2.13 average load was ca. 60%, but 1.3.7 average is ca. 80%.

So, current symptoms are with 1.3.7 compared to 1.2.13:
*) in config app "misc" tab ticking/unticking "use built-in ... filter .ts ..." produces no difference in pvrx2 behavior
*) changing audio codecs in config app "playback" tab produces no differences in behavior, even if I select ffdshow, it opens always AC3Filter
*) Recordings playback doesn't produce any audio (but playback with windows media player is ok), but in 1.2.13 it used Haali and AC3Filter and audio and video was ok.
*) It doesn't provide resume button when playing back my recordings, although it is ticked in config app; but when playing back recordings using Video Library (Video Library path is pointing to PVR recordings path) then resume is proposed as it should be
*) average CPU utilisation is higher than with previous version
*) when playing back recording, pvr couldn't "decide" how long the recording is and on OSD time bar the length time is changed by every played frame and with chaotical numbers (i.e. 0:37 then on next frame 0:52, 1:07, 1:12, 1:03, 0:54, 1:15, 0:57, etc). It lasts about 10 seconds then it has "made decision".
*) one more strange thing, when I playback the stream using windows media player or VLC, it is ok, but with GBPVR it is little bit crispier like it is playing it back in lower resolution...

The stream is: DVB-T V: PAL 720x576 25fps AVC/h.264 A: mpa

The logs are attached, link to stream sample will be included in Private message.

Any ideas?

[sub]

It is extremely sad that even with advanced configuration external .ts filters are not any more supported. May be some computers did have problems with .ts / Haali splitter, but for example my setup did work perfectly.

Sorry, but as mentioned, the Haali splitter doesnt provide everything GB-PVR needs these days. I'm not saying the Haali splitter didnt do a good job at playing .ts files, because it certainly did do a good job. That said, I need a lot of information about the transport stream, and special behaviour around live tv and playing files that are still recording, and unfortunately the Haali splitter doesnt meet these needs.

After I saw that gbpvr .ts reader is still in very early development stage and...

It was in the early stages of development a year ago. Its gone a long way since then, and works pretty well for the most part these days.

*) in config app "misc" tab ticking/unticking "use built-in ... filter .ts ..." produces no difference in pvrx2 behavior

Correct. This setting is not used in 1.3.7

*) changing audio codecs in config app "playback" tab produces no differences in behavior, even if I select ffdshow, it opens always AC3Filter
*) Recordings playback doesn't produce any audio (but playback with windows media player is ok), but in 1.2.13 it used Haali and AC3Filter and audio and video was ok.

Try the attached version to see if it helps. I suspect it'll fix the problem. This version is compatible with a wider set of audio decoders, including MPA, ffdshow etc.

*) It doesn't provide resume button when playing back my recordings, although it is ticked in config app; but when playing back recordings using Video Library (Video Library path is pointing to PVR recordings path) then resume is proposed as it should be

If you have "<UseMenuResumeButton>true</UseMenuResumeButton>" in your config.xml, then you'll get a resume button in the recordings screen popup instead of being prompted after starting playback from the recordings screen.

*) average CPU utilisation is higher than with previous version

The CPU will come down to the decoder and renderer you're using. The splitter doesnt make any notable difference itself on the CPU. You never know though, sorting out the audio decoder problem (see patch) might help your CPU usage.

*) when playing back recording, pvr couldn't "decide" how long the recording is and on OSD time bar the length time is changed by every played frame and with chaotical numbers (i.e. 0:37 then on next frame 0:52, 1:07, 1:12, 1:03, 0:54, 1:15, 0:57, etc). It lasts about 10 seconds then it has "made decision".

The attached patch should resolve this.

*) one more strange thing, when I playback the stream using windows media player or VLC, it is ok, but with GBPVR it is little bit crispier like it is playing it back in lower resolution...

GB-PVR plays no real part in this. How sharp the picture is will come down to the video decoder and video renderer you're using,

[statik]

Sorry, but as mentioned, the Haali splitter doesnt provide everything GB-PVR needs these days. I'm not saying the Haali splitter didnt do a good job at playing .ts files, because it certainly did do a good job. That said, I need a lot of information about the transport stream, and special behaviour around live tv and playing files that are still recording, and unfortunately the Haali splitter doesnt meet these needs.

It was in the early stages of development a year ago. Its gone a long way since then, and works pretty well for the most part these days.

Correct. This setting is not used in 1.3.7
Try the attached version to see if it helps. I suspect it'll fix the problem. This version is compatible with a wider set of audio decoders, including MPA, ffdshow etc.

If you have "<UseMenuResumeButton>true</UseMenuResumeButton>" in your config.xml, then you'll get a resume button in the recordings screen popup instead of being prompted after starting playback from the recordings screen.

The CPU will come down to the decoder and renderer you're using. The splitter doesnt make any notable difference itself on the CPU. You never know though, sorting out the audio decoder problem (see patch) might help your CPU usage.
The attached patch should resolve this.
GB-PVR plays no real part in this. How sharp the picture is will come down to the video decoder and video renderer you're using,

The patch worked great. I got to remove the Arcsoft decoder and now everything works with FFDshow. NetRadio plugin works now too.