[Bug] [RC2]Switching HD channels fails random

infinite.loop

Retired Team Member
  • Premium Supporter
  • December 26, 2004
    16,163
    113
    127.0.0.1
    I can confirm that after receiving the black screen and then the frozen image of the previous channel I can fix the problem by stepping forward.
    That I've seen with PowerDVD codecs.
    Any other codec wont show that behaviour here.
     

    benjerry

    MP Donator
  • Premium Supporter
  • September 26, 2007
    167
    18
    I can confirm that after receiving the black screen and then the frozen image of the previous channel I can fix the problem by stepping forward.
    That I've seen with PowerDVD codecs.
    Any other codec wont show that behaviour here.
    Sadly same problem exists here using:

    ffdshow dxva codec
    ffdshow (software) codec
    coreavc 2.0 (software) codec

    tested on livingroom client with WinXP, HD4670, Athlon64 x2 5000+

    I had much desynced audio/video with the software codecs.
     

    romuz

    Retired Team Member
  • Premium Supporter
  • July 26, 2008
    1,045
    63
    Moskau
    Hi
    i have been getting progress with my tests
    last time once i had thet error i saved ts buffer file :) yahoo :)

    Then i tested skip back, bug reproduced.

    Then i played ts buffer from videos no bug! all switched correctly

    Then i started tv wait for second ts buffer created, then replaced first one with saved buggy version and skiped back to start of ts buffer. Bug reproduced... checked it twice with restarting server and client

    That makes me think that problem is somwhere between streamingserver and tsreader.

    uploaded ts buffer on your ftp is Romuz[RC2]Switching HD channels fails random_live2-0.ts.tsbuffer1.ts

    streaming server log timestamp where bug begins is 22-04-2010 23:09:38.421

    timestamp for ts reader is 22-04-2010 23:10:25.570
     

    benjerry

    MP Donator
  • Premium Supporter
  • September 26, 2007
    167
    18
    Hi. I also did a test again and I'm uploading at the moment the timeshiftbuffer file (benjerry.ts) to the ftp site.
    The logs below belong to it.

    The test consists some channelswitching and at the end stuck on BBC HD.

    When I copy the buffer to a videofolder and start play from videosection then switching is fine apart from some blocky video in some parts, but it doesn't get stuck.

    Usually when I go back in timeshiftbuffer during tv play and so replay it then the chance on a succesfull channelswitch is actually worse then during live tv play. ~ 50% chance compared to ~ 85% during live tv.
     

    arion_p

    Retired Team Member
  • Premium Supporter
  • February 7, 2007
    3,371
    113
    Athens
    Country flag
    romuz:
    I tried the ts file you uploaded, imported it as a recording and played it from Recorded TV. Here are my findings:

    1. issue is not specific to RTSP, behavior is the same in single seat
    2. issue is not codec specific (tried ffdshow and MPC/MPV)
    3. if I set audio prefferences like yours (rus;eng Prefer AC3) at 00:56 where channel switch occurs, MP freezes until playback ends
    4. if I do not set any audio preferences, playback continues (with a small glitch) past 00:56.
    5. in both cases playback ended before the end of the ts buffer. OSD showed a length of 2:07 but playback ended at about 1:01 but that may be because ts buffer is partly filled.
    In any case I did not witness the switching back and forth between the two channels like it happens in your logs (but your logs are from live TV so it is not the same). That switching back and forth is caused by the way we seek into ts files.

    When the audio/video format changes, we rebuild the graph and try to seek to the point of the detected format change. Seeking uses a binary search algorithm that tries to approximate the byte position of the target seek time. In your logs you will notice (streaming server) that the resulting position is sometimes before and sometimes after the target seek time. The resulting position depends on the current stream duration (which in live TV changes constantly) because the domain of the search is the entire ts buffer. But when resulting seek position is before target seek time, the stream may be positioned before the channel switch and as a result cause another format change to be detected resulting in a graph rebuild, new seek and loop all over again. One way to solve this is to make sure that whenever we seek, the resulting position is never before the target seek time. I will try to build a new StreamingServer to test that theory, I fear it may have side effects.


    Nonetheless there still seems to be another issue, the one that I described above, that I cannot pinpoint. :(
     

    arion_p

    Retired Team Member
  • Premium Supporter
  • February 7, 2007
    3,371
    113
    Athens
    Country flag
    romuz & benjerry:
    Please try attached StreamingServer.dll. As always backup your original StreamingServer.dll.

    This version ensures that seeking does not end up before the target seek time. But there is a limit to the number of iterations allowed during seeking. If that limit is exceeded, the above condition cannot be ensured. If this version solves the issue I'll try to think of a way to handle this special case too. Also TsReader will need to be fixed as well.

    Edit: don't use this StreamingServer, it does not work as it should. Please find correct version in new post below
     

    Attachments

    benjerry

    MP Donator
  • Premium Supporter
  • September 26, 2007
    167
    18
    First test shows no improvement here. Especially BBC HD, ITV1 HD are troublesome.
    Shall try again later when I have time again.
     

    Users Who Are Viewing This Thread (Users: 0, Guests: 1)

    Top Bottom