hurda7 Posted May 25, 2015 Share Posted May 25, 2015 (edited) 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 bvDVBSky25.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: 2425.05.15 16:20:01.165 StartRecording: kabel eins25.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 May 25, 2015 by hurda7 Quote Link to comment
Griga Posted May 25, 2015 Share Posted May 25, 2015 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. Quote Link to comment
hurda7 Posted May 25, 2015 Author Share Posted May 25, 2015 I guess there's no way to initialize the hardware one or two seconds before recording starts? Quote Link to comment
Griga Posted May 25, 2015 Share Posted May 25, 2015 Not really. You could use a second short recording from the same transponder starting a bit earlier... Quote Link to comment
hurda7 Posted May 26, 2015 Author Share Posted May 26, 2015 (edited) 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 May 26, 2015 by hurda7 Quote Link to comment
hurda7 Posted May 30, 2015 Author Share Posted May 30, 2015 (edited) 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 May 30, 2015 by hurda7 Quote Link to comment
Griga Posted May 30, 2015 Share Posted May 30, 2015 "-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. Quote Link to comment
hurda7 Posted May 30, 2015 Author Share Posted May 30, 2015 (edited) 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 May 30, 2015 by hurda7 Quote Link to comment
Griga Posted May 30, 2015 Share Posted May 30, 2015 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? Quote Link to comment
hurda7 Posted May 30, 2015 Author Share Posted May 30, 2015 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. Quote Link to comment
hurda7 Posted May 30, 2015 Author Share Posted May 30, 2015 (edited) 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 May 30, 2015 by hurda7 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.