TVSERVER: running recordings will be interrupted - "Discontinuity header bit set!" (1 Viewer)

[rue]

Hi all!

I have the problem that my recordings will be interrupted if a new recording session will be started.

For the first look it seems the currently runnig card is reconfigured to the new frequency - so that the old record looses the stream.

--------------------------------------------- example -----------------------------------------

cut-out from tswriter.log:

31-10-2013 19:30:09.760 Recorder: RECORD set filename:E:\recorder\Dahoam is Dahoam\Schlag-artige Einsicht.ts
31-10-2013 19:30:09.761 Recorder: RECORD Received from TvService: pmt pid:0x145a serviceId: 0x2856 pmtlength:138
31-10-2013 19:30:09.761 Recorder: RECORD Old pids cleared
31-10-2013 19:30:09.762 Recorder: RECORD got pmt - tableid: 0x2 section_length: 135 sid: 0x2856
31-10-2013 19:30:09.762 Recorder: RECORD PMT parsed - Pid 0x145a ServiceId 0x2856 stream count: 8
31-10-2013 19:30:09.762 Recorder: RECORD pcr pid:0x1451
31-10-2013 19:30:09.763 Recorder: RECORD SetPcrPid clear old PIDs
31-10-2013 19:30:09.763 Recorder: RECORD stream rejected - pid: 0x622 stream type: 0x5 logical type: 0x5 descriptor length: 5
31-10-2013 19:30:09.763 Recorder: RECORD stream rejected - pid: 0x87b stream type: 0xb logical type: 0xb descriptor length: 14
31-10-2013 19:30:09.764 Recorder: RECORD add video stream pid: 0x1451 fake pid: 0x30 stream type: 0x1b logical type: 0x1b descriptor length: 3
31-10-2013 19:30:09.764 Recorder: RECORD add audio stream pid: 0x1452 fake pid: 0x40 stream type: 0x3 logical type: 0x3 descriptor length: 9
31-10-2013 19:30:09.765 Recorder: RECORD add audio stream pid: 0x1453 fake pid: 0x41 stream type: 0x3 logical type: 0x3 descriptor length: 16
31-10-2013 19:30:09.765 Recorder: RECORD add teletext stream pid: 0x1454 fake pid: 0x68 stream type: 0x6 logical type: 0x56 descriptor length: 10
31-10-2013 19:30:09.765 Recorder: RECORD add subtitle stream pid: 0x1455 fake pid: 0x50 stream type: 0x6 logical type: 0x6 descriptor length: 13
31-10-2013 19:30:09.766 Recorder: RECORD add audio stream pid: 0x1456 fake pid: 0x42 stream type: 0x6 logical type: 0x81 descriptor length: 12
31-10-2013 19:30:09.766 Recorder: RECORD SetVideoAudioObserver observer ok
31-10-2013 19:30:09.791 Recorder: RECORD Start 'E:\recorder\Dahoam is Dahoam\Schlag-artige Einsicht.ts'
31-10-2013 19:30:09.794 Recorder: RECORD start of video detected
31-10-2013 19:30:09.810 Recorder: RECORD clear TS packet queue
31-10-2013 19:30:09.811 CDiskRecorder::WriteToRecording() - Reset write buffer throttle
31-10-2013 19:30:09.811 Recorder: RECORD Info : Next broadcaster program clock reference rollover : 0 days 17:21:54 0
31-10-2013 19:30:09.842 Recorder: RECORD start of audio detected
31-10-2013 19:30:09.844 Recorder: RECORD start of audio detected
31-10-2013 19:30:09.874 Recorder: RECORD start of audio detected
31-10-2013 19:30:55.547 Recorderid 92 : Discontinuity header bit set!
31-10-2013 19:30:55.547 Recorderid 92 Continuity error... 6 ( prev 2 ) - bad signal?
31-10-2013 19:31:11.820 Recorderid 92 Continuity error... e ( prev 6 ) - bad signal?
31-10-2013 19:31:47.909 Recorderid 54 : Discontinuity header bit set!
31-10-2013 19:31:47.909 Recorderid 54 , No PayLoad, Continuity Counter should be the same ! e ( prev 6 )
31-10-2013 19:31:47.910 Recorderid ad , No PayLoad, Continuity Counter should be the same ! 8 ( prev 5 )
31-10-2013 19:32:02.707 Recorderid ad , No PayLoad, Continuity Counter should be the same ! 1 ( prev 8 )
31-10-2013 19:32:16.324 Recorderid 54 Continuity error... c ( prev e ) - bad signal?
31-10-2013 19:32:16.444 Recorderid 54 , No PayLoad, Continuity Counter should be the same ! 1 ( prev c )

-------------------- more in attachments -------------------------

The recording file is getting closed - I miss a much of data


My configuration:
Board: Intel DH77DF
OS: Win 8 64Bit
Mem: 8 GB
CPU: core i3 3225
HDD: 2 x 500 GB RAID
Grafc: Intel 4000

Thanks for any help in advance

Ruediger

 

[mm1352000]

Hello Ruediger

First, have you tried preloading your tuners? That may help.
Also: how is the signal from the satellite dish fed to the two tuners?

mm

 

[rue]

Hi ... sorry was interrupted by a Zombie (Halloween) )

Yes, of course I did this.

All signals are 90% and of high quality. I have 2 Tuners - one Pinnacle 460e via USB and one TBS6928 (PCIe).

Scanning is fine, playback is fine - everything is running when used manual.

I have never noticed this before - I think while testing the 1.5 beta I never saw this problem.

Tomorrow I will replay this version to my PC and try out what happens.

This evening I had a recording of two programs in direct follow up. So I saw 2 accesses to the TBS card - everything is fine after all.

Possibly this is only a problem when we come to an "intermix" like shown in the file as change from SD resolution to a HD channel.

About the technology:
I have a multiswitch in my technic room - two independent cables two both tuners. Nothing special ...

Thanks for your help

best regards

RUE

 

[mm1352000]

Hi ... sorry was interrupted by a Zombie (Halloween) )

Possibly this is only a problem when we come to an "intermix" like shown in the file as change from SD resolution to a HD channel.

About the technology:
I have a multiswitch in my technic room - two independent cables two both tuners. Nothing special ...

What brand/model multiswitch and LNB(s) do you use?

 

[rue]

Hi again!

I have a HUMAX Quad LNB (105) with FLS 912 switch.

Meanwhile I double checked my idea depending on versioning - the problem is still existing in Beta version.

For this case and why I did not see it before I will check the hardware and in-computer communication as the next step.

Is there any chance to see which card did draw the problem?
In the logfiles (DEBUG) I see only the steps to record but not which card would be selected.
Meanwhile I saw the problem appear on a handover on the same channel (two recordings on directly following transmissions).

best regards

RUE[DOUBLEPOST=1383323270][/DOUBLEPOST]btw... the system LNB/Switch is up for about 3 years without having a LNB/Switching problem.

But I had trouble with the mainboard and internal communications ...

best regards

RUE

 

[rue]

Hi again!

Today I double checked the LNB/Switch configuration - works fine.
I completely re-readed the sat channels and had a look on quality and field strength .. no problem, never below about 80% quality and 90% signal.
I checked the Mainboard/USB/PCIe communication and found an issue - H77 chipset did nnot initialize the hardware sometimes. In this case the PCIe card is not available in the system.

Double checked it with the timelines of my problem - did not match.

For the moment I have no solution. The only thing I found seem to be following:

Any time I get a stumbeling feed the following will be foun in the TVService.log:

[2013-11-02 16:00:08,470] [Log ] [scheduler thread] [DEBUG] - WaitForPMT: Found PMT after 0,115069 seconds.
[2013-11-02 16:00:08,470] [Log ] [scheduler thread] [INFO ] - subch:0 SendPmt:2B8E 2B8E FFFFFFFF 6
[2013-11-02 16:00:08,471] [Log ] [scheduler thread] [INFO ] - Decode pmt
[2013-11-02 16:00:08,472] [Log ] [scheduler thread] [INFO ] - Set descriptor data with length 3
[2013-11-02 16:00:08,472] [Log ] [scheduler thread] [INFO ] - Set descriptor data with length 3
[2013-11-02 16:00:08,472] [Log ] [scheduler thread] [INFO ] - PROBLEM : descriptor lengths dont match 6 9
[2013-11-02 16:00:08,473] [Log ] [scheduler thread] [INFO ] - Set descriptor data with length 3
[2013-11-02 16:00:08,473] [Log ] [scheduler thread] [INFO ] - PROBLEM : descriptor lengths dont match 6 9
[2013-11-02 16:00:08,474] [Log ] [scheduler thread] [INFO ] - Set descriptor data with length 3
[2013-11-02 16:00:08,474] [Log ] [scheduler thread] [INFO ] - PROBLEM : descriptor lengths dont match 6 9
[2013-11-02 16:00:08,475] [Log ] [scheduler thread] [INFO ] - Set descriptor data with length 3
[2013-11-02 16:00:08,475] [Log ] [scheduler thread] [INFO ] - PROBLEM : descriptor lengths dont match 6 9
[2013-11-02 16:00:08,476] [Log ] [scheduler thread] [INFO ] - Set descriptor data with length 3
[2013-11-02 16:00:08,476] [Log ] [scheduler thread] [INFO ] - PROBLEM : descriptor lengths dont match 7 10
[2013-11-02 16:00:08,477] [Log ] [scheduler thread] [INFO ] - Set descriptor data with length 3
[2013-11-02 16:00:08,477] [Log ] [scheduler thread] [INFO ] - PROBLEM : descriptor lengths dont match 10 13
[2013-11-02 16:00:08,478] [Log ] [scheduler thread] [INFO ] - Set descriptor data with length 3
[2013-11-02 16:00:08,478] [Log ] [scheduler thread] [INFO ] - subch:0 SendPMT: Channel is FTA, nothing to do.
[2013-11-02 16:00:08,478] [Log ] [scheduler thread] [INFO ] - subch:0 SetMpegPidMapping
[2013-11-02 16:00:08,479] [Log ] [scheduler thread] [INFO ] - subch:0 pid:196E pcr
[2013-11-02 16:00:08,479] [Log ] [scheduler thread] [INFO ] - subch:0 pid:1964 pmt

Problems with the descriptors or only something cosmetic?

best regard

RUE

 

[mm1352000]

Problems with the descriptors or only something cosmetic?

Cosmetic. You can ignore them.

mm

 

[rue]

Ok as long as they are less it seems uncritical for the complete recording.

I have to monitor it for a longer time.

So thanks for the moment .... possibly I come back if I have more information.

I will try next to find out if it is card dependent or a system problem.

On idea for the TVSerice .. it seems if one tv card fails after recognition the recordings will kick each other. Would be better to let the running one run and don't start the new one. Sometimes it seems that this will come to a hang ... maybe somone can monitor this.

Thanks in advance

RUE

 

[rue]

Hi again!

Ok, now I verified something inside the computer, cableing and finaly installation.

Here are the results:
- everything is ok with technical and OS installation
- the problem appears with 1.5 final
- no problem with 1.5 Beta (release candidate)
- discontinuity messages will appear in both MediaPortal variant but in Beta it seems only one frame is getting lost

What happens?
It seem there will be a sligtly change in tswriter that is responsible for the problem. My first was seems wrong.

For the moment I think tswriter is going out of sync when more than one stream are recorded and the incoming data stream is not 100% ok (frames are late or missing). It can be an idea to have a look on the complete GOP (GOV) structure. The result - if the problem appears is: a significant smaller file size of the recorded .ts and when playing the file jumps and stuttering of the video/audio. Sometimes I lost 50% of the recording. It does not depend on the channel and it's configuration itself (H264, mpeg ...). I saw it in all varaints-

Anything I can check in addition?

best regards

RUE

 

[rue]

Hi again!

Any idea on that problem?
Would it be a good idea to test against 1.6 pre?

If I make a wrong decision my children gone a kill me when I loose the x-mas sessions

best regards

RUE