DVB-C radio not working (1 Viewer)

Owlsroost

Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    There is something slightly odd in the MP_CLIENT logs - TsReader log :

    Code:
    15-04-2013 20:30:23.798 [ec8]Demux : Audio to render 0.618 Sec
    15-04-2013 20:30:54.999 [ec8]Demux : Audio to render 0.618 Sec
    15-04-2013 20:31:09.399 [ec8]Demux : Audio to render 0.618 Sec
    15-04-2013 20:31:42.799 [ec8]New channel found (PAT/PMT/SDT changed)
    15-04-2013 20:31:42.799 [ec8] pcr	  pid:  30
    15-04-2013 20:31:42.799 [ec8] pmt	  pid:  20
    15-04-2013 20:31:42.799 [ec8] audio	pid:  40 language: UNK type: MPEG2 - audio
    15-04-2013 20:31:42.799 [ec8]Setting initial audio index to : 0
    15-04-2013 20:31:42.799 [ec8]OnNewChannel: OnRequestAudioChange()
    15-04-2013 20:31:42.799 [ec8]demux:Wait for Audio stream selection :1
    15-04-2013 20:31:42.800 [ec8]OnNewChannel: New Audio 4
    15-04-2013 20:31:42.861 [990]SetAudioStream : 0
    15-04-2013 20:31:42.861 [990]Old Audio 4, New Audio 4
    15-04-2013 20:31:42.861 [990]audPin:SetAddPMT()
    15-04-2013 20:31:42.861 [990]demux:Wait for Audio stream selection :0
    15-04-2013 20:31:42.863 [ec8]Audio Continuity error... 1 ( prev d )
    15-04-2013 20:31:42.863 [ce8]audPin: Add pmt and set discontinuity L:1 B:0 fTime:0.465 SampCnt:0
    15-04-2013 20:31:42.863 [ce8]Aud/Ref : 102.494, Compensated = 102.732 ( 0.465 A/V buffers=02/00), Clk : 102.266729, SampCnt 0, Sleep 1 ms, stallPt 1.500
    15-04-2013 20:31:42.864 [ce8]Aud/Ref : 102.590, Compensated = 102.828 ( 0.560 A/V buffers=01/00), Clk : 102.267729, SampCnt 1, Sleep 1 ms, stallPt 1.500
    15-04-2013 20:31:42.905 [ce8]audPin: Set discontinuity L:0 B:1 fTime:0.807 SampCnt:2
    15-04-2013 20:31:42.905 [ce8]Aud/Ref : 102.878, Compensated = 103.116 ( 0.807 A/V buffers=01/00), Clk : 102.308938, SampCnt 2, Sleep 1 ms, stallPt 1.500
    15-04-2013 20:31:43.428 [534]Seeking beyond the end position: 2977920 > 2686520
    15-04-2013 20:31:44.500 [534]Seeking beyond the end position: 2977920 > 2714720
    15-04-2013 20:31:45.572 [534]Seeking beyond the end position: 2977920 > 2742920
    15-04-2013 20:31:46.644 [534]Seeking beyond the end position: 2977920 > 2769240
    15-04-2013 20:31:47.717 [534]Seeking beyond the end position: 2977920 > 2797440
    15-04-2013 20:31:48.789 [534]Seeking beyond the end position: 2977920 > 2825640
    15-04-2013 20:31:49.863 [534]Seeking beyond the end position: 2977920 > 2853840
    15-04-2013 20:31:50.938 [534]Seeking beyond the end position: 2977920 > 2882040

    It's getting an updated PMT in the middle of playing a live stream - the timing of it seems to co-incide (minus ts buffer delay) with stopping a recording in TsWriter log:

    Code:
    15-04-2013 20:31:42.410 Recorder: RECORD	Stop 'D:\Recorded TV\manual - Anos 60 - 2013-04-15.ts'
    15-04-2013 20:31:42.411 Recorder: RECORD	Reset
    15-04-2013 20:31:42.411 CDiskRecorder::Reset() - Reset write buffer throttle
    15-04-2013 20:31:42.412 del m_pVideoAnalyzer
    15-04-2013 20:31:42.412 analyzer: reset
    15-04-2013 20:31:42.412 del m_pPmtGrabber
    15-04-2013 20:31:42.412 del m_pRecorder
    15-04-2013 20:31:42.412 del m_pTimeShifting
    15-04-2013 20:31:42.413 del m_pTeletextGrabber
    15-04-2013 20:31:42.413 del m_pCaGrabber
    15-04-2013 20:31:42.413 del done...

    ....this doesn't seem right, starting/stopping one stream shouldn't cause PMT changes on another - any thoughts ?
     

    hello_joe

    Portal Member
    April 2, 2013
    28
    18
    Home Country
    United States of America United States of America
    Nice spotting! :)

    It looks like there is another [long standing] bug in TsWriter relating to PCR.
    In short, the issue is that a global variable which should be a constant (DR_FAKE_PCR_PID) was being modified. It just so happens that the particular test - timeshifting/recording two channels with a single tuner where the PCR PID is not the first video (TV channel) or first audio (radio channel) stream - and the method I chose to fix the original issue exposed the bug. Quite lucky!

    Updated TsWriter and patch attached.
    The idea of the patch is to use member variables to hold the original and fake PCR PIDs. The default fake PID is the constant that was previously used. The member variable is updated as the constant was previously. Probably that won't make a whole lot of sense, but the patch is attached so feel free to take a look.

    @torrinha
    Could you please be so kind to test again with the same procedure?
    Thanks in advance! :)
     

    Attachments

    • TsWriter_hunt_pcr_v3.zip
      116 KB
    • PCR_hunt_v3.patch
      10.4 KB

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    Bump....

    If you want this fix to be in a future version of MP, we need the testing feedback ;)
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    One last bump. :)
    Any update @torrinha ? I'm not able to test the patch, so there is little chance it will be added unless you are able to report.
     

    torrinha

    Portal Pro
    October 14, 2009
    55
    31
    Home Country
    Brazil Brazil
    @mm1352000 @Owlsroost
    Hi all!
    Sorry for taking so long to answer. I'm having some serious personal problems here, so I could not test the latest patch.
    So sorry for that... :(

    Regarding the aforementioned patch: can I use the file with 1.4.0 pre-release or is it possible to someone (hint: @hello_joe) compile the patch against the 1.4.0 pre-release?
    I cannot promise anything, but I'll try hard to test it in the next few days.

    Thanks for all your support...
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Sorry for taking so long to answer. I'm having some serious personal problems here, so I could not test the latest patch.
    I'm really sorry to hear that.

    Regarding the aforementioned patch: can I use the file with 1.4.0 pre-release or is it possible to someone (hint: @hello_joe) compile the patch against the 1.4.0 pre-release?

    You can use the existing file with 1.4 PR. :)

    I cannot promise anything, but I'll try hard to test it in the next few days.
    Okay. Real life comes first though, so please don't stress over testing this patch. :)
     

    mm1352000

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

    Do you remember that problem you had with the Disney channel not working (caused by missing PCR)?
    https://forum.team-mediaportal.com/threads/empty-recording-file.114065/

    I've been working on a fix for that. :)
    Please could you try the attached TsWriter?
    It seems to work okay with your old dump file, but a proper test with the live stream would be good. If you can, please be sure to check skipping forwards and backwards as well as timeshifting and/or recording.

    @Owlsroost
    I'd appreciate it if you could give this TsWriter a crack as well - mainly sanity checking on the TsReader output.
    The functional change is that we now generate PCR from the audio PTS in cases where PCR is not present, either due to PCR PID set as 0x1fff or PCR not being found in the stream 100 ms after the first video or audio is seen.
    As part of this change the DiskRecorder class has been chopped, changed and cleaned up a bit. Something I've done seems to have really slowed down zapping, and I can't figure out what it is. It's not consistent but seems to be something to do with this entry in the TsReader log:
    demux: Alert: Wait for Media change cancelled on 5 secs timeout

    Would be awesome if you could help me to figure out what is going on with this. :)
     

    Attachments

    • TsWriter [mm PCR from PTS].zip
      138.1 KB

    Users who are viewing this thread

    Top Bottom