Live-TV freezes (1 Viewer)

aalemann

MP Donator
  • Premium Supporter
  • November 19, 2012
    66
    8
    Home Country
    Germany Germany
    Hi everybody,

    first of all, I must say that I really like MP!
    My girlfriend also likes your software a lot, especially the time-shifting and recording function.

    I have, however, a small problem: Every once in a while, live-TV freezes. I just have to switch the channel and wait for a couple of seconds, then it comes back to life. This is very annoying, when you are recording something, because your recording stops then.

    I have attached today's logs, caught just after such a freeze occurred (I have deleted log-files that were not modified today, to keep the zip file small). Today, the freeze occurred when accessing the teletext, but this is not related. Sometimes it happens after 1 hour running live-tv, sometimes after 5 hours, sometimes I have to wait for more than 24 hours for this error to occur.

    Any suggestions are appreciated!
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Hello aalemann

    Did the freeze occur before or after entering the teletext?

    On the server side we have nothing really suspicious. I can see when you started looking at teletext:
    [2013-11-17 14:08:10,698] [EPG ] [EPG Update thread] [INFO ] - TimeshiftingEpgGrabber: Finished updating the database.
    [2013-11-17 14:11:18,445] [Log ] [5 ] [INFO ] - subch: start grabbing teletext
    [2013-11-17 14:11:56,756] [Log ] [11 ] [INFO ] - subch: stop grabbing teletext
    [2013-11-17 14:12:15,104] [Log ] [11 ] [INFO ] - Controller: StopTimeShifting 2

    On the client side we have:
    17-11-2013 14:10:19.871 [1859efe8] [11e8] Demux : Video to render 0.878 Sec
    17-11-2013 14:11:48.516 [1859efe8] [13e0] CTsReaderFilter::Duration - correction to predicted duration: 302926.000
    17-11-2013 14:11:52.758 [1859efe8] [13e0] CTsReaderFilter::Duration - correction to predicted duration: 302926.000
    17-11-2013 14:11:57.003 [1859efe8] [13e0] CTsReaderFilter::Duration - correction to predicted duration: 302926.000
    17-11-2013 14:12:01.252 [1859efe8] [13e0] CTsReaderFilter::Duration - correction to predicted duration: 302926.000
    17-11-2013 14:12:05.496 [1859efe8] [13e0] CTsReaderFilter::Duration - correction to predicted duration: 302926.000
    17-11-2013 14:12:09.738 [1859efe8] [13e0] CTsReaderFilter::Duration - correction to predicted duration: 302926.000
    17-11-2013 14:12:13.981 [1859efe8] [13e0] CTsReaderFilter::Duration - correction to predicted duration: 302926.000

    I'm not sure what that means, but possibly the tuner stopped streaming?
    @Owlsroost your input would be appreciated. :)

    mm
     

    aalemann

    MP Donator
  • Premium Supporter
  • November 19, 2012
    66
    8
    Home Country
    Germany Germany
    Did the freeze occur before or after entering the teletext?

    if I remember correctly, it happened after entering the teletext.

    It is, however, in general not related to the teletext, since it happened before without entering or trying to enter it. If these logs are non-optimal due to being in the teletext menu, I will upload another log-file after the next crash appeared.
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    if I remember correctly, it happened after entering the teletext.
    Thanks :)

    It is, however, in general not related to the teletext, since it happened before without entering or trying to enter it.
    Yep, understood.

    If these logs are non-optimal due to being in the teletext menu, I will upload another log-file after the next crash appeared.
    More logs are always good. I asked the question to try to understand the timing because I wasn't sure if the "correction to predicted duration" messages were related or just normal.
     

    aalemann

    MP Donator
  • Premium Supporter
  • November 19, 2012
    66
    8
    Home Country
    Germany Germany
    More logs are always good. I asked the question to try to understand the timing because I wasn't sure if the "correction to predicted duration" messages were related or just normal.

    I will upload more logs, as soon as I experience the next freeze (which will probably not be before tomorrow evening).
    Thanks for helping me!
     

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    I'm not sure what that means, but possibly the tuner stopped streaming?
    @Owlsroost your input would be appreciated. :)

    It looks like (as far as I can tell from the logs) that the timeshift buffer has stopped increasing in duration - so yes, maybe the tuner has stopped streaming.

    The number at the end of 'CTsReaderFilter::Duration - correction to predicted duration: 302926.000' is the measured actual duration of the file being played in millseconds. TsReader measures this every four seconds - in between once a second it estimates the duration, so if estimated/predicted and actual durations differ and the actual duration has not changed since the last time it was measured it logs the 'correction to predicted duration' message.

    Maybe we ought to have a 'watchdog' thread in TsWriter which checks if data is arriving at a reasonable rate (and logs something if it doesn't) ?

    Another debug thought is to log the last modification time of files when writing stops - that would tell us if writing stopped early ?
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Maybe we ought to have a 'watchdog' thread in TsWriter which checks if data is arriving at a reasonable rate (and logs something if it doesn't) ?
    I have had plans for TVE 3.5 for quite some time. ;)
    I'd like to monitor metrics from the TV library, including TS packet count (already available in TVE 3, just check more frequently), PID encrypted/decrypted state (will get callbacks on PID state change in TVE 3.5), signal strength/quality (already available in TVE 3, just check more frequently)... and use a combination of heuristics and configuration to trigger retuning, resending commands to the CI/CAM, and/or tuner reinitialisation.
    Steadily increasing TS packet count will tell us if data is arriving. Probably checking it once every few seconds would be sufficient. It might be nice to monitor all PIDs, but I don't want to drive up the CPU load too much.
     

    aalemann

    MP Donator
  • Premium Supporter
  • November 19, 2012
    66
    8
    Home Country
    Germany Germany
    Hi guys,

    thanks for taking your time looking at my problems. Sorry for answering so late, but I had a lot of work to do and therefore no time to watch TV and wait for the error to occur. However, last night I fall asleep in front of the TV :sleep: and when I woke up in the middle of the night I realized that a freeze occurred ;)

    Attached are the logs - if I understand them correctly, the freeze occurred at 2:24 am on 22.11.2013. According to my girlfriend, there was another freeze at approximately 18:41 on 21.11.2013, this data is also included in the logs - I have removed everything from the logs from previous TV-sessions to keep them small.

    Do I understand you correctly that the error seems to be due to a problem with writing the timeshift-buffer onto the harddrive?

    Thanks.
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Attached are the logs - if I understand them correctly, the freeze occurred at 2:24 am on 22.11.2013.
    I have a different interpretation. According to the TsReader log file, the timeshift buffer size stopped increasing here:
    22-11-2013 02:02:38.787 [1810efe8] [11f4] CTsReaderFilter::Duration - correction to predicted duration: 1769208.000

    MP/TsReader stopped timeshifting 22 minutes later at 2:24.
    Again I think we're seeing that the tuner is stopping streaming for some reason.

    According to my girlfriend, there was another freeze at approximately 18:41 on 21.11.2013...
    Sorry, I can't see any evidence of this. I can see that somebody was trying to tune some channels and the tuner was reporting "no signal"... but I don't see a freeze.

    Do I understand you correctly that the error seems to be due to a problem with writing the timeshift-buffer onto the harddrive?
    No. At least from my perspective, what I'm saying is that it is a problem with the tuner signal strength/quality. It looks like the tuner loses signal... and so there is no data to write to the timeshift buffer. In other words, I think you need to check your dish alignment, cabling etc.

    mm
     

    aalemann

    MP Donator
  • Premium Supporter
  • November 19, 2012
    66
    8
    Home Country
    Germany Germany
    Attached are the logs - if I understand them correctly, the freeze occurred at 2:24 am on 22.11.2013.
    I have a different interpretation. According to the TsReader log file, the timeshift buffer size stopped increasing here:
    22-11-2013 02:02:38.787 [1810efe8] [11f4] CTsReaderFilter::Duration - correction to predicted duration: 1769208.000

    OK, I see what you mean... if I remember correctly, I switched the PC off at around 2:24 and went to bed, so I was probably misinterpreting the shutting-down messages as error-messages.


    Do I understand you correctly that the error seems to be due to a problem with writing the timeshift-buffer onto the harddrive?
    No. At least from my perspective, what I'm saying is that it is a problem with the tuner signal strength/quality. It looks like the tuner loses signal... and so there is no data to write to the timeshift buffer. In other words, I think you need to check your dish alignment, cabling etc.

    it is a "community" dish at our house, which is shared by a lot of people and I have no access to it, to align it. The cabling is fine, I am already using super-low damping cable but I think I'll try an amplifier (depending on what they cost) to see if the freezes will vanish then.

    I had these kind of freezes more regularly when using MePo 1.3 (with the same hardware configuration), I therefore thought it might be due to some improvements in the TsReader that they occurred less often and that therefore there is a possibility to totally get rid of them.

    I will, however, upload the next log-files only if I am absolutely sure about the time, when the freeze occurred.
     

    Users who are viewing this thread

    Top Bottom