live tv freeze at end of show HELP!!!

[Narflex]

Have you checked to see if this works probably with SageTV 7? I'd expect the same behavior in either version since we didn't change anything in the native code on Windows at all.

My main guess here is some kind of video driver problem at this point....if you have another graphics card lying around, give that a try (or also try a different video card driver).

[SDeGonge]

FYI I'm having the exact same problem. Just upgraded from V7 to V9. V7 did not have this problem. Now, while watching live TV it will freeze on the :30 and 1:00 transition, or when the program changes (not exactly sure which). Wouldn't expect it to be the video card since all was well with V7. Could be codec/driver i guess. BTW the recording continues but the screen just freezes. If I skip fwd or back it will sync up and all is good.

[rickgillyon]

Same here, windows clients, live tv transitions. I don't watch live TV, but my wife says it only started a few weeks ago (ish).

[rickgillyon]

I've been playing about with this a bit. Watching live TV for me has a long pause after pressing play on a channel on the client, around 45 seconds, and after video starts playing the 45 seconds is in the buffer ready to play (green section of the seek bar). Obviously this is a real PITA to the people in the house who watch live TV, who are rather vocal.

This happens again when a new program starts, 45 seconds then video in the buffer. HOWEVER, if I turn off the option for "Always Tune Channel" the transition from program to program is instant, no problem.

So the issue seems to be the huge video buffer building up. This couldn't have been an issue when you first put SDEPG in the core, as I would have gone crazy checking all the channels.

Logs here, client and server, which should show the long delay tuning "Bad Robots" on ch 18 4MUSIC, then a smooth switchover to the next program.

These problems don't exist using Placeshifter, any downside to using Placeshifter instead?

[EnterNoEscape]

Does this still happen if you are watching the most recent part of the recording? I noticed this last year when people were having problems with the seamless transitions on the client and they ended up just changing fast_network_encoder_switch=true to false. The transitions only seemed to work if you were as close as possible to the end of the recording when the transition needed to happen. Otherwise, you would get the end of the recording and the transition would just hang. It's very reproducible, but I could never figure out why it was happening.

[rickgillyon]

In my case, I'm not using network encoders so don't even have that switch as far as I can see. See my message above, it seems to be a delay between tuning and presenting the video file in the client.

[EnterNoEscape]

Originally Posted by rickgillyon

In my case, I'm not using network encoders so don't even have that switch as far as I can see. See my message above, it seems to be a delay between tuning and presenting the video file in the client.

Sorry, I missed that part. In Sage.properties, you should have a global setting. Change fast_mux_switch=true to false.

[rickgillyon]

Originally Posted by EnterNoEscape

Sorry, I missed that part. In Sage.properties, you should have a global setting. Change fast_mux_switch=true to false.

Thanks, have already tried that, but I'll switch it again. Yep, no change.

And as to my message and logs above, on one client the program change is smooth with "always tune" turned off (but still slow to start first time), on other clients the pause is still there on program change.

Wife confirms only an issue a few weeks, I wonder if it's related to me setting encode_digital_tv_as_program_stream to false as advised here:
https://forums.sagetv.com/forums/showthread.php?t=63729

Will try when the house is empty!

[EnterNoEscape]

Originally Posted by rickgillyon

Thanks, have already tried that, but I'll switch it again. Yep, no change.

And as to my message and logs above, on one client the program change is smooth with "always tune" turned off (but still slow to start first time), on other clients the pause is still there on program change.

Wife confirms only an issue a few weeks, I wonder if it's related to me setting encode_digital_tv_as_program_stream to false as advised here:
https://forums.sagetv.com/forums/showthread.php?t=63729

Will try when the house is empty!

Yes, actually it very likely does have to do with that. I think I remember the behavior being different between PS and TS files on the client in regards to live TV.

[rickgillyon]

Originally Posted by EnterNoEscape

Yes, actually it very likely does have to do with that. I think I remember the behavior being different between PS and TS files on the client in regards to live TV.

So currently I have a choice of good live TV or ability to watch HD on the Android clients - not both. Ouch.

I'd replace the lot and use Android clients, but a lot of the TVs are old with no HDMI...

Getting a lot of these errors too:

Tue 12/13 16:31:30.525 [AWTThreadWatcher-SAGETV_PROCESS_LOCAL_UI@37675d] EventThread-SAGETV_PROCESS_LOCAL_UI Hang Detected - hang time = 193574 UILocker=null
Tue 12/13 16:31:30.867 [AWT-EventQueue-0@1f99aa6] Calling GraphCreated for the PluginHandler
Tue 12/13 16:31:30.867 [AWT-EventQueue-0@1f99aa6] Done calling GraphCreated for the PluginHandler
Tue 12/13 16:31:30.867 [AWT-EventQueue-0@1f99aa6] NATIVE RenderAudio called stream=1
Tue 12/13 16:31:30.867 [AWT-EventQueue-0@1f99aa6] AUDIO not rendered. No source pin found!
Tue 12/13 16:31:30.868 [AWT-EventQueue-0@1f99aa6] NATIVE RenderVideo called
Tue 12/13 16:31:30.868 [AWT-EventQueue-0@1f99aa6] Exception from line: 791
Tue 12/13 16:31:30.868 [AWT-EventQueue-0@1f99aa6] Built:sage.PlaybackException: ERROR (-4,0x80004005): There was a problem rendering the video portion of the content for playback. errCode=-4 nativeErrCode=-2147467259
Tue 12/13 16:31:30.869 [AWT-EventQueue-0@1f99aa6] VideoFrame had an error loading the file. It must abort the file load.
Tue 12/13 16:31:30.870 [AWT-EventQueue-0@1f99aa6] Tearing down playback graph

[Narflex]

The main delay in that log is from the DirectShow Demux Filter (something we wrote); likely relating to it being Transport Stream instead of Program Stream (although I'm surprised it's THAT bad). I'm surprised you need that for Android...are you using IJKPlayer or ExoPlayer? I wrote the Program Stream demux for ExoPlayer...so it *should* be working fine.

[rickgillyon]

No, this is a windows client. The Android client is fine.

[Narflex]

Originally Posted by rickgillyon

No, this is a windows client. The Android client is fine.

Then what's the problem with having it record everything in Program Stream?

[rickgillyon]

Originally Posted by Narflex

Then what's the problem with having it record everything in Program Stream?

See here: https://forums.sagetv.com/forums/showthread.php?t=63729

Summary: the HD recordings don't play back well on Android (or in many programs other than Sage). According to EnterNoEscape:

While I can see that there should be an audio track in that video, I only have a few programs that can play it back with the audio working.

The problem as I see it is that the file is an MPEG-PS file and that container doesn't support H.264 which the video definitely is

[EnterNoEscape]

Originally Posted by rickgillyon

See here: https://forums.sagetv.com/forums/showthread.php?t=63729

Summary: the HD recordings don't play back well on Android (or in many programs other than Sage). According to EnterNoEscape:

Originally Posted by Narflex

Then what's the problem with having it record everything in Program Stream?

We covered this situation back when I exposed the built in remuxer so that it it could be used by the media server. It was agreed that PS was preferred, but that TS was needed if the video stream is H.264. When H.264 is encoded into a PS by SageTV, very few programs beyond the SageTV client can even work with the file.

[panteragstk]

I'm doing some testing in this thread to see if I can re-create this issue.

[Narflex]

Originally Posted by EnterNoEscape

We covered this situation back when I exposed the built in remuxer so that it it could be used by the media server. It was agreed that PS was preferred, but that TS was needed if the video stream is H.264. When H.264 is encoded into a PS by SageTV, very few programs beyond the SageTV client can even work with the file.

Yeah....OK...now I remember. The actual problem with the huge startup delay seems to lie in the SageTV MpegDeMux DirectShow filter....and AFAIK there's nobody that's working on that code at all currently so I'm not sure what can be done about that issue.

[Fuzzy]

Originally Posted by Narflex

Yeah....OK...now I remember. The actual problem with the huge startup delay seems to lie in the SageTV MpegDeMux DirectShow filter....and AFAIK there's nobody that's working on that code at all currently so I'm not sure what can be done about that issue.

Out of curiosity, what is the sagetv demux doing that can't be done with a more off-the-shelf demux at this point?

[Narflex]

Originally Posted by Fuzzy

Out of curiosity, what is the sagetv demux doing that can't be done with a more off-the-shelf demux at this point?

I'm not sure what off the shelf options there are currently...but back in the day, there wasn't anything that was part of DirectShow that handled MPEG2 demuxing properly so we were required to write our own (I don't even think it had any kind of DirectShow filter for this when we started SageTV, there was a sample in the old DXSDK which is what we based our filter off which is why the code for it is in third_party/Microsoft)

There is a registry setting that can be used to change the Demux filter for MPEG2 PS/TS content. It requires the GUID for the DShow Filter to be set at:

HKLM\Software\Frey Technologies\Common\DirectShow\CustomDemuxGuid

The code for this option is in native/dll/DShowPlayer-2/CPlayerData.cpp

[Fuzzy]

I was just thinking, with the program being open sourced now, we might be able to look using something more mature and capable, like Haali, or LAV, unless there are special sage specific parameters being passed in. I think the LAV splitter is based on ffmpeg, so it should be pretty capable and stable.