DVBViewer Pro 5.0 - Timeshift restarted on channel data changes

[divko]

Hello!

 

DVBViewer Pro 5.0 works wonderfully for most of the time. But I have problems with Viasat History, which my cable provider sends with English and Russian audio tracks (all unencrypted, via IPTV).

 

During the commercial break my cable provider inserts their own advertisements. Consequently the channel data is changed and DVBViewer restarts the timeshift. If the timeshift was on pause, it deletes the existing timeshift file and starts playing the channel again.

 

I have found a "Auto split on channel data changes" setting under "Recorder". I guess it only works for recording proper, but it doesn't have any effect on timeshift, which is unhandled.

 

Proposed fix:

Do not restart timeshift recordings, even if channel data changes during commercial breaks

 

Attachments:

None, but feel free to contact me to do the testing

I could record the sample, if needed. That recording would probably have to be streamed to DVBViewer for testing.

[malali]

Nem megy a felvétel

[divko]

I have run TSReader on the streams.

 

Here are the results:

----------------------------------------------------------------------------------
Timeshift_02-01 19-48-22_Viasat History_content.ts
Program Number: 6490
PCR on PID 1301 (0x0515)
PMT Version: 4

Stream Type: 0x02 MPEG-2 Video
Elementary Stream PID 1301 (0x0515)

Stream Type: 0x03 MPEG-1 Audio
Elementary Stream PID 1302 (0x0516)

Stream Type: 0x03 MPEG-1 Audio
Elementary Stream PID 1306 (0x051a)

Stream Type: 0x06 ISO/IEC 13818-1 PES packets containing private data
Elementary Stream PID 1311 (0x051f)

Stream Type: 0x06 ISO/IEC 13818-1 PES packets containing private data
Elementary Stream PID 1314 (0x0522)

Stream Type: 0x06 ISO/IEC 13818-1 PES packets containing private data
Elementary Stream PID 1315 (0x0523)

----------------------------------------------------------------------------------
Timeshift_02-01 19-49-04_Viasat History_ads.ts
Program Number: 6490
PCR on PID 1301 (0x0515)
PMT Version: 5

Stream Type: 0x02 MPEG-2 Video
Elementary Stream PID 1301 (0x0515)

Stream Type: 0x04 MPEG-2 Audio
Elementary Stream PID 32 (0x0020)

Stream Type: 0x04 MPEG-2 Audio
Elementary Stream PID 33 (0x0021)

Descriptor: Registration Descriptor
Format identifier: 0x48444d56 (HDMV)

Descriptor: User Private Descriptor: 0x88
0f ff fc fc                                      ....            

----------------------------------------------------------------------------------
Timeshift_02-01 19-50-11_Viasat History_ads.ts
Program Number: 6490
PCR on PID 1301 (0x0515)
PMT Version: 5

Stream Type: 0x02 MPEG-2 Video
Elementary Stream PID 1301 (0x0515)

Stream Type: 0x04 MPEG-2 Audio
Elementary Stream PID 32 (0x0020)

Stream Type: 0x04 MPEG-2 Audio
Elementary Stream PID 33 (0x0021)

Descriptor: Registration Descriptor
Format identifier: 0x48444d56 (HDMV)

Descriptor: User Private Descriptor: 0x88
0f ff fc fc                                      ....            

----------------------------------------------------------------------------------
Timeshift_02-01 19-51-04_Viasat History_content.ts
Program Number: 6490
PCR on PID 1301 (0x0515)
PMT Version: 6

Stream Type: 0x02 MPEG-2 Video
Elementary Stream PID 1301 (0x0515)

Stream Type: 0x03 MPEG-1 Audio
Elementary Stream PID 1302 (0x0516)

Stream Type: 0x03 MPEG-1 Audio
Elementary Stream PID 1306 (0x051a)

Stream Type: 0x06 ISO/IEC 13818-1 PES packets containing private data
Elementary Stream PID 1311 (0x051f)

While "0x02 MPEG-2 Video Elementary Stream PID 1301 (0x0515)" stays the same, the audio is changed from:

- "0x03 MPEG-1 Audio Elementary Stream PID 1302 (0x0516)" to "0x04 MPEG-2 Audio Elementary Stream PID 32 (0x0020)"

- "0x03 MPEG-1 Audio Elementary Stream PID 1306 (0x051a)" to "0x04 MPEG-2 Audio Elementary Stream PID 33 (0x0021)"

[divko]

Hi!

 

I have uploaded the four video files (from my previous post) to my Dropbox account - https://www.dropbox.com/sh/op7y3vptw4qg3jf/KoEPugpJFs

 

18.146.888 A_1-Timeshift_02-01 19-48-22_Viasat History_content.ts
30.989.356 A_2-Timeshift_02-01 19-49-04_Viasat History_ads.ts
24.874.092 B_1-Timeshift_02-01 19-50-11_Viasat History_ads.ts
6.565.336 B_2-Timeshift_02-01 19-51-04_Viasat History_content.ts

 

You can merge A_1 and A_2 files into one .ts file, you will get content+ads

You can merge B_1 and B_2 files into one .ts file, you will get ads+content

You can merge A_1 + A_2 + B_1 + B_2 files into one .ts file, you will get content+ads+ads+content

 

Anyhow, while recording into another file on channel data changes is a nice feature, interrupting your timeshift is not.

 

Note: Yes, if you have ticked "Keep Timeshift File", the timeshift file isn't deleted, but still your paused timeshift is interrupted and the channel continues playing. If you want to watch the content after pause, you have to watch that file with another video player --- if you don't want to interrupt DVBViewer recording the timeshift.

[Griga]

You are right, there is a dynamic program data change. PMT version number, PMT content and audio PIDs change, subtitle streams are switched off / on. DVBViewer responds to it by kind of "retuning" the channel, which basically means a lot of internal re-initialization. Timeshift is handled as if another channel is tuned manually.

 

To be true, I don't think this behaviour will be changed, because it is not a common problem and would require fundamental structural changes in the timeshift handling. It's nothing that can be "fixed" with a few lines of code. Bad benefit-cost ratio, you know...

[divko]

would require fundamental structural changes in the timeshift handling. It's nothing that can be "fixed" with a few lines of code. Bad benefit-cost ratio, you know...

Grega, thanks for your reply.

 

I don't know the codebase, but I would not concur:

 

1. There is already an option for ordinary Recorder, namely "Autosplit on channel data changes". Make a separate GUI option like this for timeshift. Use the same handling on channel data changes when recording for timeshift as for ordinary Recorder.

 

2. Player already plays the merged TS file almost normally.

Go to Command Prompt, "cd" to your download directory for my Dropbox files and merge files with:

copy /b *.ts ViasatAll.ts

Tackling a few issues would also increase the robustness of playing the files, recorded with an ordinary Recorder, when the "Autosplit on channel data changes" setting is turned off.

 

---

Anyhow, this behavior of cable providers inserting their own commercials is not uncommon. If there are separate language/subtitle streams, you can bet that the commercials are targeted for the respective markets, which gives both cable providers and content producers a larger revenue stream. You probably won't see this on German channels, but it's common for < 10M markets (most EU countries are small).

 

I would just ask you to look into the issue. If you can't do it within a day, then leave it. But having a more robust player is a bonus, and this is an easy way to do it. I had several crashes of DVBViewer when the signal was weak. Streams appearing and disappearing. If you fix this, you'll probably fix those issues as well.

 

Thanks

Edited February 12, 2013 by divko

[Griga]

There is already an option for ordinary Recorder, namely "Autosplit on channel data changes". Make a separate GUI option like this for timeshift.

Wouldn't help. As already pointed out, timeshift is interrupted by the (re-)tuning process. The timeshift handling doesn't distinguish between manual channel switching and dynamic channel data changes. That's the point.

 

Player already plays the merged TS file almost normally

Which player with which setup? Playing the merged ts fragments was the first thing I tried, but I coudn't make it work properly in DVBViewer. The handling of such irregular files mainly depends on the DirectShow splitter/demuxer component. With the DVBViewer Filter playback got stuck at the end of the ads. Same with the LAV splitter. With the MPC splitter video/audio got out of sync... only the Haali splitter handled it correctly, but finally playback got stuck too when I tried to jump forward and backward.

 

I doubt that a (timeshift) file resulting from "just go on recording" is a reliable and generally stable solution, particularly with DirectShow based playback where other (configurable) components are involved that are not part of DVBViewer. IMO it would be necessary to completely hide such changes from the downstream components by avoiding things like long audio gaps and timestamp discontinuities, which tend to be deadly for the DirectShow timing. Or to keep track of the PMT content and stop / reinitialize playback on each change, analogous to retuning in case of a live stream, but additionally considering that the user may jump forward / backward to a random position. A difficult task...

 

Anyhow, this behavior of cable providers inserting their own commercials is not uncommon.

Up to now you are the only one reporting this particular issue. There are some satellite channels on Astra 19° East that dynamically switch over to local news and back to the main video/audio streams - that's why the Auto Split mechanism was introduced. It would be difficult to record the local news without it. But the change only happens once a day, and people don't seem to bother about a timeshift interruption in this case.

 

I would just ask you to look into the issue.

I'm contributing some things here, but I'm not directly involved in DVBViewer Pro coding. So don't expect too much from me.

 

I had several crashes of DVBViewer when the signal was weak.

Here very rarely. May depend on the configuration - see above - and also on the DVB device and the driver. Don't forget: DVBViewer is a front-end for a whole lot of hardware and software components. They all may crash when fed with chaotic data.