Jump to content

Stream error at start of recording with Playback off


Recommended Posts

With DVBViewer being open and "Playback Off" selected (aka the default -c parameter for recordings using the Task Scheduler), when a scheduled recording starts, the first recording on a transponder always has one stream error right at the start of the recording (0:00:00).

 

When another recording starts of a second channel on the same transponder, still with "Playback off", there's no stream error at the start.

 

Checking the first recorded TS with mpeg2repair has something like this as its first result:

 

Sequence Frame 6(0-X) / Time 0:00:00 :
VideoWarning: Discontinuity of (2+) packet(s). First packet ending at offset 50196

 

In the DVBViewer-debug-log, occassionaly there's this entry (last line):

 

25.05.15 16:20:00.686 VCR-Internal Starting recording.
25.05.15 16:20:00.814 TBDADVBSky Opendevice bvDVBSky
25.05.15 16:20:00.814 TRecording AllocateHardware TT-TVStick CT2_4400v2 DVB-C Tuner (2)
25.05.15 16:20:00.814 StartRecording TT-TVStick CT2_4400v2 DVB-C Tuner (2)
25.05.15 16:20:00.814 TBDADVBSky SetTuner TType: 0, Freq: 370000, Symrate: 6900, LOF: 0, Tone: 0, Pol: 5, DiseqC: 0, FEC: 0, APID: 3011, VPID: 3001, PMT: 3000, SID: 2006, SatMod: 0, DiseqCVal: 0, NID: 1537, Flags: 24
25.05.15 16:20:01.165 StartRecording: kabel eins
25.05.15 16:20:01.170 VCR-Internal Recordingstart.
25.05.15 16:20:01.286 ParseSI Bad CRC

When Playback is not off, this particular stream error never happens

Even if DVBV has to change the frequency for the recording, there's no stream error as long as Playback isn't off.

 

Changing the "Direct Tuning"/"Stop stream before tuning"-options don't help.

Edited by hurda7
Link to comment

Most likely caused by the hardware / driver on initialization, because It starts delivering data before the process has reached a stable state. My old TechniSat SkyStar S2 (with WDM/Network driver) shows the same behaviour.

Link to comment

Always having to schedule (and remember) to set an "intialization"-recording doesn't sound too thrilling to me.

And the need to have playback on just had negative sideeffects. I had playback enabled to workaround this problem, forgot to disable it after recording started, and shortly after recording started, during a burst of CPU-load, something caused several stream-errors due to the added load of decoding (dxva on nvidia) the HDTV-transmission. :(

Edited by hurda7
Link to comment

I think I found a workaround by using these parameters for scheduled recordings: -c:3432018142642241546 -x16386

"-c:3432018142642241546" for tuning the channel with that ID

"-x16386" for firing the action "Disable Audio/Video".

Using that, the stick is initialized before the actual recording starts (LED is on), thus no error happpens at the start.

 

I tried other actions like "Stop Graph" and "Close Graph", but they not only stop playback but also deactivate the tuner again right after tuning the channel defined by -c:*

"Stop Renderer" didn't work either.

 

Now I just need to find a way to deal with scheduled recordings while DVBViewer is already running, but playback is off.

Edited by hurda7
Link to comment
"-x16386" for firing the action "Disable Audio/Video".

 

Clever idea. This action stops the filter graph, as you can see on the Settings -> Filters -> DVB Source property page, but does not remove it, so playback remains in a kind of standby state with low memory usage (compared to the running state) and almost no CPU usage.

Link to comment

If I could force the DVBViewer-scheduler to not force the -i flag, that would be the icing on the cake. ;)

 

But the problem kind of solved itself: I cannot get to stick to work on any of my Windows machines anymore.

From one moment to the other it refused to work in Windows. Pretty much only minutes after I wrote the previous posting.

In DVBViewer's Channel Scan, the "Signal"-meter is changing when I change the position of the antenna, so I guess the stick is working in some way, but that's it. No channels found, no channels can be tuned. No error in the debug-log either.

 

What's really weird: The stick works fine in Linux.

Even when using it in a virtual machine on top of a Windows-machine, it's working. Blind-scan, auto-modulation, everything.

 

If some power-surge (or whatever) killed a part of the stick, it shouldn't be working in Linux anymore either.

 

This is easily the weirdest problem I've ever had.

Edited by hurda7
Link to comment
If I could force the DVBViewer-scheduler to not force the -i flag, that would be the icing on the cake.

 

You wouldn't like that icing. Every time when a recording starts in the background it would stop playback, because the MS Task Scheduler launches the application even when it is already running -> second DVBViewer instance starts -> recognizes that an instance is already running -> sends the command line params to the first instance and terminates -> first instance executes the command line params. That's what -i prevents.

 

I cannot get to stick to work on any of my Windows machines anymore.

 

Shut down the PC, disconnect it from the power supply, wait some seconds, reboot. Or re-install the driver.

 

BTW: Doesn't the stick run with a special firmware under Linux?

Link to comment

You wouldn't like that icing. Every time when a recording starts in the background it would stop playback, because the MS Task Scheduler launches the application even when it is already running -> second DVBViewer instance starts -> recognizes that an instance is already running -> sends the command line params to the first instance and terminates -> first instance executes the command line params. That's what -i prevents.

Yes, true.

But when I have set the existing instance of DVBViewer to "Playback Off", a scheduled recording isn't tuning a channel and executing the -x action due to the -i flag. Result: Stream error at the start of the recording.

 

Shut down the PC, disconnect it from the power supply, wait some seconds, reboot. Or re-install the driver.

I'm through all of this on three machines, several times.

System-restore, driver removal and reinstall, shutdowns.

 

BTW: Doesn't the stick run with a special firmware under Linux?

That firmware, or firmwares for both the demod and tuner, are part of the Windows-driver too, and they're uploaded during the initalization of the stick.

 

If that's not working in Windows, I don't see why it should work in Linux. And why it stopped working from one second to the next. I haven't changed anything OS- or hardware-wise.

Link to comment

Remote is working in DVBV, too.

So weird.

Using an USB-sniffer could help, but I wouldn't be able to understand such a log.

Edited by hurda7
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...