Jump to content

Restart recording if [x] errors in [y] seconds


beeswax

Recommended Posts

OK so I've been using DVBViewer Recording Service for ages now with a TBS 6981 satellite card. For the most part, the results are great however once in a while, a recording will start from a timer and it will be glitch city. Tens, hundreds and sometimes as in the case just now, thousands of discontinuities in the first minutes of recording. If the user doesn't intervene, these errors simply continue throughout the whole recording and the result is an unwatchable recording. Example from just now:

 

QuoteQuoteQuote

 

BBC Two HD 15/01/2015

 

Device: TBS 6981 BDA DVBS/S2 A Tuner/Demod (1)

18:25:04 / 00:00:00 (~ 0.00 MB) Start
18:25:05 / 00:00:01 (~ 0.41 MB) Errors: 1042
18:25:05 / 00:00:01 (~ 0.41 MB) PID 5500: H.264 Video, 16:9, 1920x1088, 25 fps
18:25:05 / 00:00:01 (~ 0.41 MB) PID 5501: AC3 Audio Stereo, 48 khz, 192 kbps
18:25:05 / 00:00:01 (~ 0.41 MB) PID 5502: MPEG Audio Stereo, 48 khz, 256 kbps
18:25:06 / 00:00:02 (~ 1.03 MB) Errors: 1599
18:25:08 / 00:00:04 (~ 1.65 MB) Errors: 1554
18:25:09 / 00:00:05 (~ 2.48 MB) Errors: 1897
18:25:11 / 00:00:06 (~ 3.21 MB) Errors: 1773
18:25:12 / 00:00:08 (~ 3.75 MB) Errors: 1406
18:25:13 / 00:00:09 (~ 4.41 MB) Errors: 1730
18:25:14 / 00:00:10 (~ 4.98 MB) Errors: 1424
18:25:15 / 00:00:11 (~ 5.89 MB) Errors: 1462
18:25:16 / 00:00:12 (~ 6.57 MB) Errors: 1465
18:25:18 / 00:00:13 (~ 7.14 MB) Errors: 1378
18:25:19 / 00:00:15 (~ 7.80 MB) Errors: 1409
18:25:20 / 00:00:16 (~ 8.52 MB) Errors: 1345

 

and so on and so on. The fix is always simple - stop the recording (toggle the timer off) and immediately re-enable it thus restarting the recording - now the recording is nice and clean. This element of uncertainty and randomness is really frustrating and it would be really useful if there could be a built in function which restarted a recording in these sorts of cases. The user should be able to customise the threshold for considering a recording borked.

 

This may well be a device driver issue or Windows problem but we all know the odds of getting that fixed if that's the case, sometimes we just have to work around the **** Microsoft and hardware vendors give us.

 

I wrote this AutoIt script a while back to try and solve the problem and it works fairly well but it's a very clunky and dirty way of trying to do this: http://pastebin.com/7sQ2W9Pi I imagine restarting a timer after x errors could be achieved in a much cleaner way within DVBViewer itself. Thanks.

Edited by beeswax
Link to comment

Hello,

 

this is a very good idea! I hope this problem could be fixed by a DVBViewer function or plugin too.

 

 

Many Greetings

 

Webturtle

 

Link to comment

Hello,

 

this is a very good idea! I hope this problem could be fixed by a DVBViewer function or plugin too.

 

 

Many Greetings

 

Webturtle

Link to comment
  • 1 month later...

Ugh, just happened again. 3130 errors in just under 59 mins, recording is completely useless. Of course, a simple stop/start of the timer after a couple of mins of continuous errors would have prevented this >:(

Link to comment

:thumbsup: thumbs up for this idea! I too have got a few recording (two or three) spolied over the years exactly this way, without beeing abled to pinpoint the actual cause.

Edited by majstang
Link to comment

If there are multiple recordings on on this same TV card. Do they have all errors at the same time?

 

Sort of, it's tricky to explain but I'll try to use the example from the other day to illustrate (there were several recordings ruined not just the one I mentioned above)

 

So my timers list for that evening looked like this:

 

19:00 - 20:00 BBC2

19:30 - 20:00 BBC4

20:00 - 21:00 BBC2

20:00 - 20:30 BBC4

 

BBC2 HD and BBC4 HD are on different transponders so both tuners were used for this line up. I have 5 minute buffers set before and after all recordings so all start/stop times are +/- 5 mins the above.

 

The very first recording of the evening started off fine, no errors were logged until the exact moment the first BBC4 programme started (19:25). This BBC4 programme logged a crazy number of errors and what's worse, caused the same for the remainder of the BBC2 show. So if a recording has this problem then it will also ruin anything happening on the other tuner and will continue to do so until that tuner stops being used (or the timer on the "bad tuner" is toggled off/on).

 

Because BBC4 had back to back recordings, the errors continued into the second BBC4 programme, and the second BBC2 programme too. The errors on BBC2 stopped at the exact time the last BBC4 timer stopped (20:35).

 

So in summary, DVBViewer can successfully start a recording on 1 tuner but then start a glitchy one immediately or shortly afterwards on the second tuner. If one of the tuners is producing a glitchy recording, it will also shaft the recording on the other tuner until it stops being used. As I've said, a straight off/on of the timer always fixes this if I'm around to spot it and intervene. My AutoIt script that I linked to in the first post does solve the problem (and I've started using it again now!) but an inbuilt solution would be greatly appreciated.

Edited by beeswax
Link to comment
  • 2 weeks later...

There are a lot of things to do in the DVBViewer an the Recording Service.

And the question is what has the highest priority for the developers.

 

And workarounds for problem which don't fix the real problem, haven't the highest priority.

 

So if there are no other changes in this area of the code, which make it easy to include this functionality. I don't would expect it in the foreseeable future.

Link to comment

pls. attach a support.zip and describe your sat-setup.

 

I don't believe you've read the whole thread.

 

There are a lot of things to do in the DVBViewer an the Recording Service.

And the question is what has the highest priority for the developers.

 

And workarounds for problem which don't fix the real problem, haven't the highest priority.

 

So if there are no other changes in this area of the code, which make it easy to include this functionality. I don't would expect it in the foreseeable future.

 

That's disappointing. Workarounds do fix problems by the way. While the root cause would be nice to tackle, it's most likely not even an issue within DVBViewer to blame plus the infrequency and randomness of the problem makes diagnosis next to impossible. Still, if no dev wants to commit time to this, there isn't much I can do so I'll just leave it there. Anyone else who suffers this is welcome to use the AutoIt script I posted, if you make any improvements to it, please let me know.

Link to comment

This used to happen regularly for me with one particular card - the error went away when I change cards. I always worked on the assumption that there was an error in the datastream and the error handling in the card did not allow it to recover elegantly. It is the joy of digital - one piece of screwed-up data and the whole thing fails.

 

It doesn't have to be like this though. Restart the timer and the recording continues without a problem - it is quite literally a case of turning it off and on again to solve the problem. And since it is not caused by a problem with the software, it is not really a workaround, but a means of solving a data glitch.

 

So I would also like to see this implemented.

 

C.

 

 

Link to comment

 

I don't believe you've read the whole thread.

I did, that's why I asked for more information. maybe you requested a workaround for problem that could be easily solved otherwise.

Link to comment

Same "problem" here too. Different DVB-S(2) cards on different OS(Win7,WinXP). When this happens all following recordings are broken too. A simple stop/restart of the recording fixes it(if i "catch" it). Right now i just restart the Recording Service from time to time and in between recordings and all is fine. Support.zip would not help as it happens only from time to time and i use plugins :innocent: that could be the cause too. No Mediacenter,DVBViewer or any other program here that could "block" the card..it just happens. :iiam:

Link to comment

Well this suggestion seems to have a fair bit of support behind it amongst other users. In the interests of keeping this alive and maybe finding a fix or workaround if it can't be fixed :P I've attached a support.zip

 

My system:

 

Gigabyte Z77X-D3H

Core i7 3770k, 16GB RAM

MSI GeForce GTX 980 Gaming TwinFrozr (NVidia driver 347.88 WHQL)

TBS 6981using driver 2.0.1.7

 

The 2 occurrences of the problem which I've reported here appear in the debug log at timestamps:

15.01.15 19:05:00

03.03.15 19:25:04

 

I've given a very detailed description of the second occurrence just above in post #7.

support.zip

Edited by beeswax
Link to comment

Still, if no dev wants to commit time to this, there isn't much I can do so I'll just leave it there. Anyone else who suffers this is welcome to use the AutoIt script I posted, if you make any improvements to it, please let me know.

I had a glitchcity episode on one of my recordings (RS) recently. I have two DVB-C dual tuners where three was recording and the fourth streaming to DVBV. All three recordings had the same starttime and errors in start of log. In one of the recordings the errors continued for an hour. Maybe I could adapt this script approach of yours. Care to elaborate what the improvements you mentioned may include? You also mentioned the script is clunky and uses dirty tricks, care to elaborate on those as well?

Link to comment

I had a glitchcity episode on one of my recordings (RS) recently. I have two DVB-C dual tuners where three was recording and the fourth streaming to DVBV. All three recordings had the same starttime and errors in start of log. In one of the recordings the errors continued for an hour. Maybe I could adapt this script approach of yours. Care to elaborate what the improvements you mentioned may include? You also mentioned the script is clunky and uses dirty tricks, care to elaborate on those as well?

 

When I said dirty, I just meant it's not got any access to the internals of DVBViewer or making full use of an API to communicate with it. All interactions with DVBViewer RS are done by scraping log files, parsing recording directories and invisibly opening/parsing recording service web pages.

 

Improvements-wise, I knocked this together in what little free time I have so there's no doubt efficiencies to be made and maybe some "dirty" functions could be replace with something better like an API call.

 

At the moment, you'd need to change the path to your recorded TV and then compile the script however I might have some time this coming week to get it pulling your recording locations automatically then I could distribute it as a compiled exe.

Edited by beeswax
Link to comment
Thanks beeswax!


Ah yes, i see what you meant by "dirty". I was hoping to study your script and convert it to autohotkey which is my preferred language. The autoit syntax is rather different, but i should be abled to figure it out. Regarding the RS API calls there are possibilities to edit, delete and recreate timers which maybe can be used to stop and restart a faulty recording http://en.DVBViewer.tv/wiki/Recording_Service_API. I haven't played around with those particular API calls before, but will do as soon as i get time. The COM interface for DVBViewer there should be ways to stop and restart timers directly. Don't think many people are using DVBViewer for recording though. Earlier there was a whitepaper covering the DVBViewer COM interface in the download section.


Regards

majstang

Edited by majstang
Link to comment
  • 9 months later...

Thumbs up for this suggestion!

 

This happens to me, too, with a TBS 5922, so it might be a TBS driver related problem. First I thought that the reception was bad when this happend, but I sometimes had messed up recordings with thousands of errors while reception on the TV was completely normal.

 

So many recordings have been messed up in the past...

I understand that the devs have many other things to add and fix and that it is a matter of priority.

So, here are at least 5 users having that problem (and having posted about it in the forum)... ;-)

And at least in my low-level-programming-skilled mind, I don't imagine this being too complicated, checking for the error rate and stopping/starting the recording once.

Maybe there's still hope.

 

Meanwhile, I will give the script of yours a try, beeswax, thanks! Do you have an updated versiono available or is it safe to use the one you posted initially?

Link to comment

Hi Connum, I did in fact fix a bug not long ago which would occur when 2 recordings were active, might have fixed some other stuff, can't remember. I also made it so all variables can be set at the top, no more hard-coded URLs. Here is the script as it stands currently: http://pastebin.com/VmzuGTSJ

 

Also, I don't think _XMLDOMWrapper is included in AutoIT as standard so here's that (drop into Program Files (x86)\AutoIt3\Include): http://pastebin.com/KkigPPjH

 

To use, install AutoIt and open the main script in the editor. Set the $RecordingPath variable to your Recorded TV folder. Set the $DVBip to the IP address the recording service is running on and $DVBport to your DVBViewer port (default port is 8089). Click [Tools] -> [Compile] and save the exe somewhere. Set it to run on startup.

Link to comment

Thanks! I didn't have the patience and ran straight into the XMLDOMWrapper error with the old script version before you posted your answer! :D

 

Now it seems to run as intended. I will let it run to see if it catches some of the failing recordings in the next days.

 

By the way, I needed a username and password for my RS, so I simply added that in front of the IP in the form username:password@127.0.0.1 - works lilke a charm! :)

 

Adding multiple recording dir support would be great. I haven't worked with AutoIt before, but I might be able to achieve that myself. Do you think using several instances of the script (with adapted recording dir and log filename) cause any issues or should this work fine until I have the time to implement this for my needs?

 

Any plans on making this available as a git repo so one can fork it and make pull requests if adding features like username/password in a variable or the said multiple recording dirs?

 

Cheers!

Link to comment

You can whitelist your machine so it doesn't get asked for the username/password if you like by adding this section to C:\ProgramData\CMUV\DVBViewer\Config\svcuserdata.xml:

 

<section name="TrustedDevices">
<entry name="0">192.168.0.2</entry>
</section>

 

I wanted to add stuff like multiple recording directories but I have hardly any free time, and probably won't for a while (two under-2s in the house). I've no idea how to setup a git so if you know how and want to, please feel free to publish it there, I'd love to see some improvements myself. Not tried several instances of the script - you'd need to set a new $ResponseXMLpath for each instance. Probably wise to have a new $DebugFile as well. Other than that, it should work.

Link to comment

Thanks for the fast responses. I didn't know about that TrustedDevices feature, cool!

I will set up a repo soon and post it here. And I'll also give the multiple instances a try.

Link to comment

The repository can be found here:

https://github.com/Connum/DVBViewer-recording-check

 

Everybody's welcome to fork, contribute, send in pull requests...

 

@beeswax I can add you as a contributer if you like, just PM me your email address or GitHub username if you have one. Don't fear if you're not familiar with GitHub, you can even edit the files directly without the need for a Git client.

Link to comment

Nice work Connum, looks good. I'd add the GitHub link to the OP but this forum doesn't let you edit posts of a certain age. PMing you now.

Edited by beeswax
Link to comment

Hi! I will post a topic in the English and the German section.

 

\\edit: Oh, I see that I don't have the rights to do so.

Edited by Connum
Link to comment

Another messed up recording rendered useless... :-(

As the script only checks the first few minutes, it missed the recording going bonkers about half an hour into recording. Might be necessary to change the script in order to monitor each recording until it's finished. But we can discuss this in its thread in the addons section.

 

I know it's the damn TBS drivers, but a built-in "restart recording when errors detected" would realy have helped here...

Strangely enough, the recoring was indeed split two times, however, the second time there have not even been any errors at all.

2016-01-18_21-48-37_BBC One HD (AC3,eng)_Silent Witness - 3 5. Part 1 Life Licence An ex-convict is killed.log

2016-01-18_22-23-40_BBC One HD (AC3,eng)_Silent Witness - 3 5. Part 1 Life Licence An ex-convict is killed.log

2016-01-18_22-32-15_BBC One HD (AC3,eng)_Silent Witness - 3 5. Part 1 Life Licence An ex-convict is killed.log

Link to comment

That's something different to what I've always seen and what the script was designed to handle. Are you sure a second tuner didn't start a recording at 22:09? In my experience, this issue always occurs within the first minute (usually only a few seconds) of a recording starting. The only times I've seen recordings go haywire further into the broadcast is when the second tuner starts a bad recording. This then causes errors in both recordings from the time recording 2 started.

 

Post #7 goes into excruciating detail on this so I won't explain again but are you sure that's not what happened here? Also, why has the recording been split? The problem with the issue this script is meant to address is that DVBViewer is always oblivious to it. It seems to me that DVBViewer did think something was wrong with this one and stopped/started twice because of this. Could this be a legitimate case or poor signal?

 

Either way, if you adapt the script to handle this, can you make it a separate fork or something? Or make the full recording monitoring completely optional? I personally don't want every recording to be monitored in it's entirety.

Edited by beeswax
Link to comment

Sure, I would add that as an option, not as a compulsory behaviour of the script.

 

The second tuner was idle at the time. I even analyzed the stream of the tuned transponder with TransEdit while the recording was running and producing the errors (with the same tuner) and it showed no discontinuities. So the signal was definitely ok, no other tuner did interfere... I don't understand what's happening there... :(

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...