Duplicate Recording Timers after Autosearch Timer

[majstang]

I get "some" duplicate timers after executing an Autosearch Timer. Can not imagine why.

This is the Search EPG:

 

 

 

When the recordingtimers is set i then bring up a new Search EPG and choose the preset How I met your mother. When pressing search this shows up:

 

 

 

All timers should be in yellow, but they are not...meaning i will get two duplicates when executing the Autosearch Timer.

I cant explain why. Hope somebody else could?

 

 

Edited June 7, 2010 by majstang

[Lars_MQ]

make sure you have no duplicates in your channellist.

[majstang]

There is no duplicates in DVBViewer channellist that could explain my issue.

[majstang]

I did some more testing in order to detect some kind of pattern when these duplicates recording timers show up. This time selecting a show which is very frequently sent on different channels. The test is done according to the earlier method from post 1:

When the recordingtimers is set i then bring up a new Search EPG and choose the preset "Jims värld". When pressing search this shows up:

 

 

All searchresult should be marked in yellow (because they already exists as timers), but they are not...meaning i will get a lot of duplicates when executing the Autosearch Timer.

 

1. If two episodes is broadcasted/recorded right after each other on the same day the second show will be a duplicate.

Many examples of this in picture 2. Shows started:

09.00-09.30

09.30-10.00 this one will duplicate

13.45-14.10

14.10-14.40 this one will duplicate

 

As if Recording Service cant handle when two episodes is recorded with no time marginal at all in between each other.

 

2. Cant explain why every show which starts 01.05-01.35 gets duplicated.

 

Edit: another possibility is when the name of the show includes swedish caracters like å, ä and ö it tends to be more duplicates...

Edited June 7, 2010 by majstang

[majstang]

Hmm...when reflecting over previous use of DVBViewer (mainly 4.2.1) without rec service installed I did sometimes experienced when setting up recordings directly from EPG Window that some shows did not turn RED when sending them to PVR. It was often like this for one of the episodes if two episodes were broadcasted with no time margin in between each other.

 

When checking Recording Timers in DVBViewer the timer which not turned red in the EPG Window was there...and the show always got recorded as it should so I didnt think it was a big deal. Didnt realize this could render these kind of consequences when using RS. So if RS is innocent of this crime, what could cause it?

 

I use latest XEPG.

Testing this with DVBViewer beta .150 (not connected to RS) shows the same thing

No duplicates in channellist.

Edited June 8, 2010 by majstang

[bogdan1980]

maybe it's XEPG fault.

[majstang]

maybe it's XEPG fault.

No, if deleting the epg.dat which is created by XEPG and then let the EPG which comes from my TV-provider to update epg.dat, i get the same issue. So XEPG cant have anything to do with this.

[majstang]

Ok, finally i got some time to test whats up with RS when i get duplicate timers after executing autosearch timers.

Turns out whatever you do DO NOT SET:

Configure-->Recordings-->One Click Programming (EPG):

Time Before (min) =0 and Time After (min) =0

If you do you will get the duplicate timers as described above.

Setting these to some positive value (especially Time After) and everything works as it should.

So @Lars bug or not?

Edited June 8, 2010 by majstang

[majstang]

Since developers do not have anything to say about this i wanna make a suggestion. Several people have requested this before and being denied, but they didnt have very special pro arguments in thier favor. Im talking about introducing the possibility to schedule seconds in recording service. Of course it will be a problem if setting One Click Programming (EPG)) to 0 minutes. What happens is if two recording is set to record right after each other will mean these recordings will overlap eachother with one minute. Consequence of this is the duplicate timers you get after autosearch timers.

If it would be possible to use seconds when scheduling these recordings you will be abled to set for example:

First show 9.30.00-9.59.59

Second show 10.00.00-10.29.59

 

Then the overlapping issue will be gone.

When being forced to set positive values in The One Click Programming (EPG) it is quite annoying when the first show you recorded contains for example 1 minute of the second show and the second show have 1 minute cut out. I wanna have complete recordings and not chopped up ones forcing me to edit them in after hand.

[Jeremyl]

Hi Mjastang...

 

I found this GPL license (free) tool, it works in Windows, and it might allow modification of the database.

 

http://sqlitestudio.one.pl/index.rvt?act=download

 

I copied files to my laptop and started to look at them.

I see what looks to be all the recording service information in this SQLITE V2 data base.

So... I would think some hot shot could write a simple screen to make it easy to modify start and end times by a few seconds. I would, but there is so much to do, and so little time. If only I could reset my biological timer! I really don't know what I am looking at. It sure would be nice to have one of the software writers give us some help.. maybe by posting the database parameters?

 

Some of the below is my own fiddling around....

C:\Documents and Settings\KWMD\Desktop\afoo>ls

C:\Documents and Settings\KWMD\Desktop\afoo\*.*

foo-foo.htm sqlitestudio-1.1.3.exe

MediaDatabase.db SvcDatabase.db

MusicDatabase.db2 TimerDatabase.db

sqlite-3_7_0.zip timetst

sqlite3.exe timetst.db

sqlite3_analyzer-3.7.0-win32.zip tvdatabase

sqlitebrowser_200_b1_win.zip TVDatabase.db

12484608 (12459813) bytes in 14 files

 

And here is a little sample of some data exported into a spreadsheet.

CWD LIVE A (1) 0 0 1713 40364.5 g:\satellite\capture\inside-edition\07-05_12-00-02_cwd live a (1)_inside-edition.mpg

CWD LIVE B 0 0 1714 40365.46 g:\satellite\capture\insider\07-06_11-00-02_cwd live b_the insider.mpg

CWD LIVE A (1) 0 0 1715 40365.5 g:\satellite\capture\inside-edition\07-06_12-00-02_cwd live a (1)_inside-edition.mpg

CWD LIVE B 0 0 1716 40366.46 g:\satellite\capture\insider\07-07_11-20-57_cwd live b_the insider.mpg

CWD LIVE B 0 0 1717 40366.46 g:\satellite\capture\insider\07-07_11-25-01_cwd live b_the insider.mpg

CWD LIVE A (1) 0 0 1718 40366.5 g:\satellite\capture\inside-edition\07-07_12-00-02_cwd live a (1)_inside-edition.mpg

CWD LIVE B 0 0 1719 40367.46 g:\satellite\capture\insider\07-08_11-00-02_cwd live b_the insider.mpg

GDMX 6/4 (eng) 0 0 1720 40375.38 g:\satellite\capture\animal-atlas\07-16_09-02-16_gdmx 64 (eng)_animal-atlas.mpg

GDMX 6/6 (eng) 0 0 1721 40375.42 g:\satellite\capture\maury\07-16_10-20-06_gdmx 66 (eng)_maury.mpg

GDMX 6/6 (eng) 0 0 1722 40375.42 g:\satellite\capture\maury\07-16_10-24-33_gdmx 66 (eng)_maury.mpg

GDMX 6/2 (spa) 0 0 1723 40378.38 g:\satellite\capture\coldcase\07-19_09-12-00_gdmx 62 (spa)_.mpg

Edited July 22, 2010 by Jeremyl

[Jeremyl]

nope... I was into a dead end... look at this one:

C:\Documents and Settings\All Users\Application Data\CMUV\DVBViewer\config\svctimers.xml

 

And it would be VERY easy to modify. Already includes seconds!

 

Sample viewed with Wordpad:

 

<Timer Type="1" Enabled="-1" Priority="50" Date="21.07.2010" Start="15:59:59" End="18:00:00" Days="TTTTT--" Action="0">

<Descr>My-Net</Descr>

<Options AdjustPAT="-1"/>

<Format>1</Format>

<Folder>G:\satellite\Capture\My-Net</Folder>

<NameScheme>%date_%time_%station_%event</NameScheme>

<Log Enabled="-1" Extended="0"/>

<Channel ID="1116340225|G16/19 SD (eng)"/>

</Timer>

 

I have an XML editor that checks for errors. I think that would be a better tool than Wordpad, but lets give this a try. Notice the once second ahead start so that the begining of the feed will have one second to begin the stream to disk.

Edited July 22, 2010 by Jeremyl

[majstang]

Sweet! I have worked with the timerlist many times when writing my hibernationscript for RS but i didnt freakin realize I already had the tools to make a script to alter the timers start and end time quite easily with this autohotkey script as base:

 

msgbox % UrlDownloadToVar("http://xxxxx:xxxxxx@127.0.0.1:8075/api/timerlist.html[?utf8=]")

UrlDownloadToVar(URL, Proxy="", ProxyBypass="")
{
AutoTrim, Off
hModule := DllCall("LoadLibrary", "str", "wininet.dll")

If (Proxy != "")
AccessType=3
Else
AccessType=1
;INTERNET_OPEN_TYPE_PRECONFIG                    0   // use registry configuration
;INTERNET_OPEN_TYPE_DIRECT                       1   // direct to net
;INTERNET_OPEN_TYPE_PROXY                        3   // via named proxy
;INTERNET_OPEN_TYPE_PRECONFIG_WITH_NO_AUTOPROXY  4   // prevent using java/script/INS

io_hInternet := DllCall("wininet\InternetOpenA"
, "str", "" ;lpszAgent
, "uint", AccessType
, "str", Proxy
, "str", ProxyBypass
, "uint", 0) ;dwFlags

iou := DllCall("wininet\InternetOpenUrlA"
, "uint", io_hInternet
, "str", url
, "str", "" ;lpszHeaders
, "uint", 0 ;dwHeadersLength
, "uint", 0x80000000 ;dwFlags: INTERNET_FLAG_RELOAD = 0x80000000 // retrieve the original item
, "uint", 0) ;dwContext

If (ErrorLevel != 0 or iou = 0) {
DllCall("FreeLibrary", "uint", hModule)
return 0
}

VarSetCapacity(buffer, 512, 0)
VarSetCapacity(NumberOfBytesRead, 4, 0)
Loop
{
 irf := DllCall("wininet\InternetReadFile", "uint", iou, "uint", &buffer, "uint", 512, "uint", &NumberOfBytesRead)
 NOBR = 0
 Loop 4  ; Build the integer by adding up its bytes. - ExtractInteger
   NOBR += *(&NumberOfBytesRead + A_Index-1) << 8*(A_Index-1)
 IfEqual, NOBR, 0, break
 ;BytesReadTotal += NOBR
 DllCall("lstrcpy", "str", buffer, "uint", &buffer)
 res = %res%%buffer%
}
StringTrimRight, res, res, 2

DllCall("wininet\InternetCloseHandle",  "uint", iou)
DllCall("wininet\InternetCloseHandle",  "uint", io_hInternet)
DllCall("FreeLibrary", "uint", hModule)
AutoTrim, on
return, res
}

 

I dont know what happens with the timers though when updating svctimers.xml later on with script, if they go red (inactivated) i will be forced to manually activate them one by one.

[majstang]

Nah, this wont work! Cant update webinterface timers after changing starttime in svctimers.xml. Doesnt matter if stopping RS, restart RS, reboot HTPC.

This change must be done by the developers and since they have done the major part already, seconds in svctimers.xml, i dont think introducing seconds when scheduling timers would be that big of a step. It is the autosearchtimer part in combination with scheduling seconds that would be the complicated bit. I think that is why they decided to scrap seconds, which apparently was intended from the beginning if judging from the timerlist start and end time format. Well, we really need a solution to this as soon as possible. The timebuffering method is CRAP from beginning til end.

Edited July 22, 2010 by majstang

[Jeremyl]

humm... I don't understand much about the system, or what your script is attempting to do. I'm guessing that whatever triggers the "Record" event must get its information from the SCVTIMERS.XML, and I would think that file is output when you change the WWW screen setting. So, if you change a time in the XML, does the trigger time change? If so, then I would think it easy enough for someone (even me) to write a WWW page to read and write the same page, or maybe even rewrite the WWW form. I remember seeing some HTML files.

 

I have not tried modifying the XML file yet. Also, I get no EPG... no schedule metadata with the signals I must record, so if you need to recieve and modify that data, then what you want may not be applicable to what I need.

Edited July 22, 2010 by Jeremyl

[majstang]

I'm guessing that whatever triggers the "Record" event must get its information from the SCVTIMERS.XML, and I would think that file is output when you change the WWW screen setting. So, if you change a time in the XML, does the trigger time change?

Damn, this is confusing! I managed to successful schedule recording timers with seconds by changing trigger time in SVCTIMERS.XML. The accurate way to do it seem to be. Stop RS (rightclicking systray icon and stop service), change trigger time in svctimers.xml, restart RS. Then it works and the recording starts on the second exactly.

 

BUT when i first tested this I failed every time because all my already existing webinterface timers vanished after restarting RS and I have NO idea on why.

[majstang]

Hmmm...scheduling recordings with seconds works great as long as you use recording timers NOT created by AutoTimers and AutosearchTimers. If having one recording timer created by AutoTimer/AutosearchTimer it will be possible to scheduling seconds, but if having two or more recording timers created by AutoTimer/AutosearchTimer the recording will fail. Strange anomalie to say at least.

Conclusion, because I only use recording timers created by AutosearchTimers it wont be possible for me to make a script that alter svctimers.xml trigger time to include seconds. This will only be possible on manually created recording timers and recording timers created with SearchEPG.

 

Moreover, as long as webinterface uses timeformat hours:minutes with no seconds I will still get duplicate recording timers when executing my AutoSearchTimers (if setting timebuffer to 0=minutes), even if scheduling seconds had worked on recording timers created by AutoSearchTimers. The only thing i had prevented was getting clipped recordings, so no satisfying cure. Best thing would be to wait and see if developers could create a solution.

Edited July 22, 2010 by majstang

[majstang]

Blasted...i didnt see it...my earlier observations was wrong! There is no anomalie its an unicode thing. If svctimers.xml contains any recording timers with characters like å, ä and ö the timerslist will vanish and render unusable when trying to schedule trigger time with seconds (this happens in third step when restarting RS). This has nothing to do with autosearchtimers. Now im completly astonished, cuz svctimers.xml is in unicode like everything else in Recording Service and i really dont know why im having this issue.

[Jeremyl]

Hi Mjastang. I have not had time to play with this yet, but what I would expect is that data stored in an open web page might interfere with changes to the XML. In other words, do not remain logged into the system until you are done changing the xml.

 

I would think to make this workable we need a hook to make the data base manager, maybe an embedded SQLITE, to reload the data from the XML. Finally, you would want to have all that happen in a modified duplicate of the web page that is now part of DVBViewer recording service. I would hate to have to stop and start the service just to load a new XML, as then you could not change stuff while recording. However, restarting SQLITE would be easy. I guess you would have to try to decompile DVBViewer to get this stuff... and the developers would HATE that!!

 

By the way, I have had RS running now for almost two days, at times recording 3 feeds simultaneously, and thus far I have seen no problems. This stuff though during the early morning back up operation.. while at the same time files were being transferred via FTP to the playback machine..."An error was detected on device \Device\Harddisk2\D during a paging operation." It is too bad I had to start this project with marginal computer hardware.

[Jeremyl]

hi majstang: Looks as though the developers make it easy. Look at the SDK, and buy Delphi. http://www.DVBViewer.com/download/sdk.zip For example...

 

procedure onAddRecord(ID: Integer);

The event gets fired whenever a new Timer is added.

 

Parameters

ID

ID of the newly added timer.

 

So... you can write your own stuff. Time to get cracking.

[majstang]

Hi Mjastang. I have not had time to play with this yet, but what I would expect is that data stored in an open web page might interfere with changes to the XML. In other words, do not remain logged into the system until you are done changing the xml.

Im not logged in when changing the xml (with RS stopped). All my 145 recording timers vanishes anyway when change in xml is saved and I start up RS. Logging in and then check timers they are all lost and this is caused by an unicode error somewhere. Testing with recording timers without å, ä and ö in the title, scheduling seconds works great and all recording timers remains visible and updated with the new triggertime, seconds excluded of course in the webinterface but they are in play non the less.

 

I would think to make this workable we need a hook to make the data base manager, maybe an embedded SQLITE, to reload the data from the XML. Finally, you would want to have all that happen in a modified duplicate of the web page that is now part of DVBViewer recording service. I would hate to have to stop and start the service just to load a new XML, as then you could not change stuff while recording. However, restarting SQLITE would be easy. I guess you would have to try to decompile DVBViewer to get this stuff... and the developers would HATE that!!

Sounds intriguing I must say. Yes, developers would hate that We are pretty much alone here and cant expect any help from devs and

since my HTML knowledge is on newbie level I cant help out any further Im afraid. However, if you get it to work it would be very intresting to see your solution.

 

Regards

Majstang

[Jeremyl]

I won't be trying anything too soon. I need to see RS work for a week without any changes before I begin to try anthing out of the ordinary. I am still having computer disk write errors that cause a tv program file to dissapear. "An error was detected on device \Device\Harddisk2\D during a paging operation." Disk 2 is a 1.5 TB sata drive used by DVBViewer to save program and log files.

 

You might try editing with XMLwriter, as it checks rules to assure your XML edit is correct. http://xmlwriter.net/ I don't know if DVBViewer's SDK works for the Recording Service, or if you want to become a computer software developer, but if you have time (I don't) to write code, and funds to get Delphi, but that looks like the way to get the changes we both need. I am unsure the beta RS is writtein in Delphi. It is easy to inspect the executible files and find out.

 

Of course we COULD have tried to do this in Linux with Myth-TV. I did a year or two ago on a machine I use for email, but found I needed an NTSC or PAL type monitor output just to set up and quit trying as that computer is pretty busy doing other things.

[majstang]

You might try editing with XMLwriter, as it checks rules to assure your XML edit is correct. http://xmlwriter.net/

Yes, you were right! Using XMLwriter fixed the problem with lost recording timers. I was using notepad when editing the xml earlier and this bad boy seem to screw up the utf-8 encoding when saving the xml after triggertime change.

 

 

I don't know if DVBViewer's SDK works for the Recording Service, or if you want to become a computer software developer, but if you have time (I don't) to write code, and funds to get Delphi, but that looks like the way to get the changes we both need. I am unsure the beta RS is writtein in Delphi. It is easy to inspect the executible files and find out.

Im quite sceptical it would be possible to make this work as wanted. The hard part is how to handle scheduling of seconds when using AutoserachTimers (which autocreates recording timers based on Search Presets and EPG). These recording timers will get the start time (trigger time) according to what the EPG specifies. Usually this means recording starts on full hours, half hours and so on. I would hate to be forced to sit and manually change trigger time on each recording timer one by one. If having 200 recordingtimers that would be unthinkable. To avoid getting in that trap requires some kind of really smart script which autoreschedules svctimers.xml according to this example:

 

- Every show with start time on full hour 10:00:00 changes to 09:59:59

- Start time on half hour 10:30:00 changes to 10:29:59

 

In other words the script resets every starttime by 1 second earlier than original trigger time. This must me optional so there is a possibility to reset starttime with what ever you like in the range from 0 to 59 seconds back and forth the original triggertime. Do you think you would be abled to create such a function? I would not in Delphi or HTML (whatever RS is coded in), that much I can assure you. However I would be abled to create such a script in Autohotkey...and this would not require any HTML pages, Delphiknowledge or anything. Only drawback is this script must be executed manually with RS stopped otherwise the triggertime changes wont be updated, but that one I can live with.

 

No, Delphi is not my cup of tea, I will leave that one for you

Edited July 24, 2010 by majstang

[majstang]

Ok, scheduling seconds script in RS is finished and I can only say time spent on this was a waste. After extensive testing i did not find any way to workaround the duplicate recording timers issue after executing AutosearchTimers by tweaking starttime or endtime of the recording timers in svctimers.xml. Duplicate timers issue arise when having Timebuffer (beginning and end) on 0 minutes to avoid getting clipped recordings. Only way to circumvent this would be to do the same changes as done in svctimers.xml in the epg.dat as well. Since epg.dat is a binary file I have no easy access to the data in it and cant do the corresponding changes in it as I did in the svctimers.xml. If this had been possible in an easy way there would be NO more problem with duplicate timers, cuz when the Autosearchtimer creates new recording timers the already existing recording timers would have the same starttime and endtime in epg.dat as in svctimers.xml, therefor no duplicate timers.

I see no point in going further with this project. Giving up now and can only hope developers will come up with something genius to get rid of both clipped recordings and duplicate recording timers.

 

I wont be using the script as it is now. I rather have clipped recordings than a lot of duplicate recording timers. The script performs really well if having Timebuffer Beginning at 0 minutes and End at 1 minute. As long as not lowering endtime with more than a minute (if using that feature) you will avoid getting duplicate timers and you will be abled to play around with scheduling of seconds on recording timers starttime (or endtime). For those very few who may be intrested in the scheduling seconds script I will post it in the Script section soon.

 

Regards

Majstang

[Jeremyl]

hummm.... I don't get EPG with my material, as what I use is not intended for home viewing. And as almost all our programs are recurring weekly, or weekdays, we just enter them once. I have only one that really needs a fix of a few seconds. I might even talk the uplink into scheduling the program to run a few seconds earlier so that I need not change the timer.

 

 

Also, you could find it interesting that I have changed the registry to force NTP time lookup every 15 minutes instead of Windows default of several hours. With this change, a Windows computer stays within a fraction of a second of coordinated universal time. Anyway, maybe, for my purposes I can just modify DVBViewer/web/timer_new.html to have a table showing seconds. I wonder if that will work? Looks easy. Would a developer person care to respond?

 

I'm still not ready to try dealing with seconds, as I still have to see my old computer run a week without a problem. I'm using an old AMD XP +2700 and my theory about the system crashing is that the PCI slot socket plastic connectors have changed dimensions enough that connections have become unreliable. I have had a lot of problems with them, and just maybe, even though it works for a while, after a few days a connection becomes bad and corrupts processes.

 

So far as I can tell, Recording Service Beta is working just fine. But until I can get a full week I am not going to attempt to modify any table or XML. Tomorrow I will try to buy a new multi PCI slot main board. And I guess I am ready to spend money to build a second machine with PCIe slots, and different receivers. Technisat only makes PCI.

 

Friday July 30th was my most recent reboot. If it still is running next Friday, I will feel good.