DVB-C radio not working (4 Viewers)

[Owlsroost]

I'd appreciate it if you could give this TsWriter a crack as well - mainly sanity checking on the TsReader output

Is this a TVE3 compatible TsWriter (not TVE3.5) ? - if so, I'll drop into my test system.

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

I'll take a look (but it might not have time today). Can you attach the TsWriter and TsReader logs please ?

(the 'demux: Alert: Wait for Media change cancelled on 5 secs timeout' message basically means TsReader has found that something in the stream has changed which may require a graph rebuild - due to the channel change e.g. different audio format, video format or frame size - but it's waiting for a response from MP player and it's not happened, possibly because MP thinks it's not necessary. Maybe there is a mis-match between what's in the PAT/PMT and the video/audio streams themselves ? Need the logs to tell you more)

Tony

 

[Edalex]

@mm1352000 unfortunately, I changed my cable provider. And aldo I think they probably fix it.
Maybe we ca somehow vanish PCR from stream to check your patch or broadcaast my file with vlc to tv server or smth

 

[mm1352000]

Is this a TVE3 compatible TsWriter (not TVE3.5) ? - if so, I'll drop into my test system.

Yes, TVE 3 compatible. I transplanted the DiskRecorder and PMT parser classes.

Can you attach the TsWriter and TsReader logs please ?

Full logs attached.
Started with Choice TV - seemed a little slow to start given I preload my tuner.
However the change from Choice to TV 3 (HD) was much slower. For a period of time I saw black screen, presumably while TV Server was changing channel. Then I saw a frozen image of Choice TV for a couple of seconds, then finally TV 3 kicked in.
You can see an unusual delay here:

[2014-03-25 09:53:49,531] [ 87d0048] [ 678] - demux: Alert: Wait for Media change cancelled on 5 secs timeout
[2014-03-25 09:53:53,296] [ 87d0048] [ 9ac] - DeMultiplexer: First Gop after new PAT, 1920x1080 @ 16:9, 25.000Hz interlaced

(the 'demux: Alert: Wait for Media change cancelled on 5 secs timeout' message basically means TsReader has found that something in the stream has changed which may require a graph rebuild - due to the channel change e.g. different audio format, video format or frame size - but it's waiting for a response from MP player and it's not happened, possibly because MP thinks it's not necessary. Maybe there is a mis-match between what's in the PAT/PMT and the video/audio streams themselves ?

Hmmm, there shouldn't be a mismatch, but I'll investigate that avenue of enquiry to make sure. Thanks for the tip.

 

[mm1352000]

unfortunately, I changed my cable provider. And aldo I think they probably fix it.

Hmmmm, okay. Oh well!
I do still have the old dump you provided which seems to work now. So I was fairly confident that the code works, just wanted to double check.

Maybe we ca somehow vanish PCR from stream to check your patch or broadcaast my file with vlc to tv server or smth

Yep, maybe. I'll see if I can do that.

 

[Owlsroost]

Looking at the TsReader log:

[2014-03-25 09:53:44,515] [ 87d0048] [ 9ac] - New channel found (PAT/PMT/SDT changed)
[2014-03-25 09:53:44,515] [ 87d0048] [ 9ac] -  pcr      pid:   30
[2014-03-25 09:53:44,515] [ 87d0048] [ 9ac] -  pmt      pid:   20
[2014-03-25 09:53:44,515] [ 87d0048] [ 9ac] -  video    pid:   30 type: H264
[2014-03-25 09:53:44,515] [ 87d0048] [ 9ac] -  audio    pid:   40 language: eng type: LATM AAC
[2014-03-25 09:53:44,515] [ 87d0048] [ 9ac] -  audio    pid:   41 language: eng type: AC3
[2014-03-25 09:53:44,515] [ 87d0048] [ 9ac] -  Subtitle pid:   50 language: eng type: DVB subtitle 2
[2014-03-25 09:53:44,515] [ 87d0048] [ 9ac] - Setting initial audio index to : 0
[2014-03-25 09:53:44,515] [ 87d0048] [ 9ac] - DeMultiplexer: We have a video stream, so we let the mpegParser check/trigger format changes
[2014-03-25 09:53:44,515] [ 87d0048] [ 9ac] - demux:Wait for media format change:1

........

[2014-03-25 09:53:44,625] [ 87d0048] [ 254] - demux:Wait for Audio stream selection :0
[2014-03-25 09:53:49,531] [ 87d0048] [ 678] - demux: Alert: Wait for Media change cancelled on 5 secs timeout
[2014-03-25 09:53:53,296] [ 87d0048] [ 9ac] - DeMultiplexer: First Gop after new PAT, 1920x1080 @ 16:9, 25.000Hz interlaced
[2014-03-25 09:53:53,296] [ 87d0048] [ 9ac] -   H.264 I-FRAME found 24.624000
[2014-03-25 09:53:53,296] [ 87d0048] [ 9ac] - DeMultiplexer: triggering OnVideoFormatChanged

...it's taking nearly 9 sec from the point that the PAT is changed to it finding the first GOP (hence the 'Media change' timeout - could anything be delaying the video/audio TS packets being written to the file (or are their PIDs wrong for a while, so they get discarded in TsReader) ?

 

[mm1352000]

There is indeed a sequence of events required to start writing to file, and it is a bit complex. In general the principles are:

• don't write to file at all if all video and audio is encrypted
• don't write to file at all until PCR is received (or in the now-supported case: until we determine that PCR is not available and start generating PCR from PTS, which requires a PES header containing PTS from an audio PID)
• don't write a given PID to file until a TS packet with the payload unit start flag set is received... with the exception of the PCR PID (or audio PID that we're using to generate PCR), for which we will write any packet as soon as PCR is received or generated

The goal is to deliver TsReader a timestamp for sync and a clean entry point on each PID (hence the complex third requirement) right up front. In the third condition the exception for the PCR stream is to avoid creating a discontinuity, because the packet carrying PCR is not necessarily also going to be the start of a PES packet.

From a file perspective, the PAT will be the first packet written to the file; the second will be the PMT; the third will be a packet containing PCR which may or may not contain the start of a PES packet. Following that will be all packets from the PCR source PID... and the packets from the other PIDs will appear as soon as we see a payload unit start flag.

I'm not sure whether any or all of these conditions are necessary but they basically mirror what was in the code already. It should not take 9 seconds for this sequence to complete. In fact, you can see it happens extremely quickly in this example:

[2014-03-25 09:53:44,515] [4b54f18] [250] - Recorder: TIMESHIFT start of video and/or audio detected, wait for PCR
[2014-03-25 09:53:44,515] [4b54f18] [250] - Recorder: TIMESHIFT PCR found, value = 4369634549, compensation = 4221659977, next broadcast program clock reference rollover in 0 days 13:01:32 0
[2014-03-25 09:53:44,515] [4b54f18] [250] - Recorder: TIMESHIFT clear TS packet queue
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::WriteToTimeshiftFile() - Reset write buffer throttle
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 376 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 564 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 940 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 940 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 940 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 940 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 940 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 1880 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - Recorder: TIMESHIFT PID 450 start of video detected
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 1880 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 1880 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 1880 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 1880 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 3760 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 3760 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 3760 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 6016 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - Recorder: TIMESHIFT PID 410 start of audio detected
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 7520 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - CDiskRecorder::Flush() - Throttle to 9400 bytes
[2014-03-25 09:53:44,515] [4b54f18] [250] - Recorder: TIMESHIFT PID 400 start of audio detected

Video/audio is seen, quickly followed by PCR. Since the PCR is carried in the video PID TsWriter will be writing the video stream to disk from that point forward (hence the relatively quick ramp on the throttle). We don't write the audio content until the "start of audio" entries which correspond with the payload unit start flag being seen on those PIDs, but even that is nowhere near 9 seconds later. Obviously this doesn't correspond to GOPs... but TsWriter doesn't do that level of analysis.

 

[mm1352000]

Ahhh, problem solved.
I needed to bump the PAT version on channel change. If what I was seeing is representative of what happens when PMT changes (ie. a dynamic PMT change without channel change)... it seems not very... optimised.

[edit: Updated version attached for anybody who would like to test. Definitely compatible with MP 1.6 PR and newer. Probably compatible with older versions too.]

 

[Sebastiii]

Will try this version too for regression
You know that i have some IPTV channel where PMT change in live (from start of tuning channel), for my IPTV provider, we think that it stream from different server.
I need to try that even if it will not work as before, i can test the regression lol

 

[Sebastiii]

Hi

Not sure is usefull and maybe something on my side, i have see just try and 'No PMT found' appear twice and i try to tune other channel and was ok after.

 

[Sebastiii]

Here a new one :
V1 : PMT not Found
V2 : PMT not Found
V3 : PMT Found

@georgius too