Jump to content

Disable duplicate timers?


Recommended Posts

Hi,

 

I read with interest in the latest beta update about after auto update any recordings found that exist in the timer list or recordings already are added as inactive.

 

So I updated all my saved searches and cleared my timer list, then ran an autotimer.

 

But all of the recordings are still active, even the duplicate ones.

 

Is there anything else I need to do to enable this? It would be very useful.

 

I'm really interested to see where you go with this. I think a lot of good possibilities open up if you're storing EPG ID numbers with timers. Thanks for looking at this.

Link to comment
I read with interest in the latest beta update about after auto update any recordings found that exist in the timer list or recordings already are added as inactive.
Not the timer list. Only the recordings db.

 

Add: Webinterface/Auto search: You can now select if the auto search should compare it's results with the recordings db (Title and/or Event). If a result is found in the db the auto search will create a DEACTIVATED timer.

For this to work, the recordings db has to be up to date and all recordings must be present.

Link to comment
Add: Webinterface/Auto search: You can now select if the auto search should compare it's results with the recordings db (Title and/or Event). If a result is found in the db the auto search will create a DEACTIVATED timer.

This needs some clarification. I dont understand quite. This add refers to reruntimers will be inactivated in timerslist after autoseach if the title and EPGeventid is the same found in the recordings db. Does the rerun has the same EPGeventID as the already recorded show in recordings db? I thought these EPGeventIDs varies from show to show, so how will the matching be carried out then?

Edited by majstang
Link to comment

If Title = the subtitle and/or Event = the title exist in the recordings db, new created timers (via Auto search) will create a DEACTIVATED timer.

Link to comment

If Title = the subtitle and/or Event = the title exist in the recordings db, new created timers (via Auto search) will create a DEACTIVATED timer.

Ok, still dont understand! You cant use only title as a matcher cuz that will make all future to come recordingtimers with that title inactivated after autosearch. There must be some kind of match (same EpgID or description) in both recordings db and the autosearch result to make this work. Dont think the epgid is the same if comparing, for example show 1 recorded a week ago to the rerun airing let say tomorrow. If there is no match the rerun tomorrow will not be inactivated in timerslist using this feature.

Link to comment

The auto search dose not change any existing timers (even if thy where created via exact this auto search).

Only new created timers will create a deactivated timer.

Link to comment

The auto search dose not change any existing timers (even if thy where created via exact this auto search).

Only new created timers will create a deactivated timer.

Yes, of couse this is for new timers only. That was not unclear in any way. I think the developer knows what im talking about. If this works that would be true greatness, now it is time to test it out :bounce: and see if I get the same result as Uglyned :bye:

Link to comment

This works as I suspected it would! If checking "Title" box (the lower one) for search presets all future to come timers gets deactivated...not really good cuz that means the show in question will not get recorded any more. If checking the "Event" box (the lower one) only, no new timers appears at all. Same result if having both "Title" and "Event" checked. An another quirk I did encounter was if using Delphis EPG Format Editor in XEPG version 5, the "Title" option for search presets will not work either. Delphi might have to make the EPG Format Editor optional in the future and not mandatory as it is today. Downgrading to an earlier XEPG version did the trick. Hopefully there will be a chance the "Event" option will work in next RS beta. REALLY liking the potential of this new feature and it will be a blast to use it later on :bye:

Edited by majstang
Link to comment

Hmm this feature had potential but doesn't seem to hit the mark.

 

Most programmes I watch are on weekly. Like every Monday, something like that. Then they're repeated a few times through the week until a new episode is shown next Monday.

 

Freesat and Freeview have a 7 day EPG. So, say the EPG search does its thing today and finds the next episode of my show on next Wednesday, and adds a timer event.

 

That timer event will be in my timer list for 7 days, becasue that's how far ahead the EPG is. Say there is a repeat on Wednesday night, then on Friday, then on Tuesday. All of those events will be picked up as timers while the first showing of my show is still a timer, because the show won't have been on yet. So they'll all still be added.

 

I may watch the show live whe it's on, or shortly after it's shown, from the recordings list, then delete it. So this functionality will never actually be used for me.

 

Can you give any indication of future uses for this new data that you're storing with timer events? Are you looking at adding series link or EPG search entries from the DVBViewer? I know that would be really useful to me, as I've already said quite a lot - too much probably.

 

One more thing - I don't know if it was there all along - but when I was snooping through svctimers.xml I noticed that every new timer event logs how it was created - and if it was created from auto search, which auto search it was created from. This is really useful to me as sometimes random timer events are created from rules that are too general. It's good to know which rule triggered it, because I can go in and make it more specific. Have you got any plans to use the 'timer source' data anywhere else or do I need to snoop through svctimers.xml every time?

 

Thank you for all your continued work on this, I don't know of any other software in the media centre / dvb area that improves and develops so quickly.

Link to comment

Hmm this feature had potential but doesn't seem to hit the mark.

 

Most programmes I watch are on weekly. Like every Monday, something like that. Then they're repeated a few times through the week until a new episode is shown next Monday.

 

Freesat and Freeview have a 7 day EPG. So, say the EPG search does its thing today and finds the next episode of my show on next Wednesday, and adds a timer event.

 

That timer event will be in my timer list for 7 days, becasue that's how far ahead the EPG is. Say there is a repeat on Wednesday night, then on Friday, then on Tuesday. All of those events will be picked up as timers while the first showing of my show is still a timer, because the show won't have been on yet. So they'll all still be added.

 

I may watch the show live whe it's on, or shortly after it's shown, from the recordings list, then delete it. So this functionality will never actually be used for me.

Well, the case you're describing assumes there is no entries to match against in recordings db. When starting out using this feature and the recordings db is empty this will be unavoidable and something one have to accept. When the recordings db grows things will get better. In my case, to make the feature even more accurate, I do plan to have only one day worth of EPG and execute the autosearch daily, as long as this feature only works for new timers and are not abled to change status on existing timers. I believe the feature requires a perfect recordings db and if deleting recordings from RS webinterface, after watching them, this recording entry will be deleted from recordings db on the spot and consequently all reruns for this show will be recorded. If deleting the recording from the explorer instead the entry will remain in recordings db until refreshing and cleaning of recordings db. Might be a good idea to frequently take manual backups of the svcdatabase to avoid complete dataloss in case of an accidental refresh/cleanup. This since there is no way of reinsert lost entries once the recording/mediafile is deleted. RS has no rec db backup task either.

 

In the past I did it the same way as you, record-watch-delete...never bothered much in keeping a perfect recordings db, but now (or soon at least) there will be a good reason for doing it. :bye:

Edited by majstang
Link to comment

Hi Majstang!

 

You can restore the DVBViewer recording database, if you have the epd-info.txt files or the log-files. Just copy them to *.mpg and refresh the database. Then you can delete the "mpg" files again. I don't know if this works with RS too.:unsure:

 

There's only on problem: My DVBViewer consumes a giant amount of ram, if there are many recordings in the database without the corresponding *mpg files. I had moved the mpg files to a USB-HD. The used ram was up to 2 GB :(. After cleaning the database the used ram was only 67 MB.

 

 

With many Greetings

 

Webturtle

Link to comment

Hi Majstang!

 

You can restore the DVBViewer recording database, if you have the epd-info.txt files or the log-files. Just copy them to *.mpg and refresh the database. Then you can delete the "mpg" files again. I don't know if this works with RS too.:unsure:

 

There's only on problem: My DVBViewer consumes a giant amount of ram, if there are many recordings in the database without the corresponding *mpg files. I had moved the mpg files to a USB-HD. The used ram was up to 2 GB :(. After cleaning the database the used ram was only 67 MB.

 

 

With many Greetings

 

Webturtle

Webturtle...you rock :thumbsup:

Never thought about trying that approach, mostly since the moderator did say it was impossible without the actual mediafile. To my surprise it turns out it is possible to fool RS as well :original: To make it work I had to select both "Create EPG information file" and "Create Log file" in RS-->configuration-->Recorder. When deleting the actual mediafile (from the explorer) and refreshing database the entry gets removed from rec db as expected (having only the .txt and .log files in the recordingfolder). Then if renaming the .log file to .ts and keep the .txt as it is...the entry gets reinserted into the recordings database after refresh db :D Tried the opposite also...renaming the .txt to .ts and leaving the .log file alone, but that did not work when refreshing.

 

Thanks for this excellent suggestion, this makes the manual step of saving the SvcDatabase unnessecary...set it and forget it and the db data is now safe in case of an accidental refresh occurs after the actual mediafile/recording has been deleted.

 

Cheers,

majstang

:bye:

Edited by majstang
Link to comment

Hi Majstang!

 

I would prefer to copy the *.txt file to *.mpg not to rename it. So you can rebuild the database as often as necessary.

 

 

Many greetings

 

Webturtle

Link to comment

Hi Webturtle!

 

Unfortunately I'm not abled to get it to work the way you are describing. RS seem to require the EPG information file having the .txt extension. Changing extension on the .txt gets refused (the .txt can't mimic the actual mediafile .ts) and if copying the .txt to the backup folder and in the same time changing extension to .ts gets refused as well.

 

To make it work I had to put a "dummy" file (created with Notepad or whatever) in the same folder and with same name as the EPG information file .txt, but change the extension on it to .ts. Then you are abled to restore this database entry after refresh. In other words, two files seem to be the minimum requirement for RS...the .txt and a "dummy" .ts.

 

To automate this fine little way of backing up the recordings database I made a script for it here:

http://www.DVBViewer.tv/forum/topic/45486-automatically-delete-recordings-older-than-x-days/page__view__findpost__p__338697

 

Here I'm moving the .txt to my backup folder and moves and changing extension on the .log file to .ts. Works beautiful :)

 

Have a nice day and weekend, webturtle! And again big thanks for sharing your skills :bye:

 

Regards

majstang

Edited by majstang
Link to comment

Hi Majstang!

 

I don't see your problem.  :blushing:  I meant I would prefer to copy the EPG-Info.txt file to a file with the same name and the extension .mpg, leaving the EPG-Info.txt and the Log.log files in the DVBViewer recording order as they had been before. The copied TXT-file becomes the Dummy.mpg file. Because the txt file is copied not renamed this can be done as often as necessary.

 

Here an example:

 

Demo.txt, Demo.log, Demo.mpg - Demo.mpg is deleted

 

Demo.txt Demo.log - creating the dummy mpg-file: copy Demo.txt Demo.mpg

 

Demo.txt, Demo.log, Demo.mpg (alias Demo.txt) - Recording.db can be refeshed

 

I hope it is now a bit more clear, what I meant.

 

This works with my normal mpg-recordings (no EPG as fileinfo, create information file and write extended log file) and the normal DVBViewer.

 

 

With many greetings

 

Webturtle

Link to comment

I meant I would prefer to copy the EPG-Info.txt file to a file with the same name and the extension .mpg, leaving the EPG-Info.txt and the Log.log files in the DVBViewer recording order as they had been before. The copied TXT-file becomes the Dummy.mpg file. Because the txt file is copied not renamed this can be done as often as necessary.

Aha, I guess I missunderstood you :blush: The main thing is...it works beautiful to restore the database when mediafile is deleted :thumbsup:

Never thought it could be done :biggrin:

 

Best regards

majstang

Link to comment
  • 3 weeks later...
Add: Webinterface/Auto search: You can now select if the auto search should compare it's results with the recordings db (Title and/or Event). If a result is found in the db the auto search will create a DEACTIVATED timer.

For this to work, the recordings db has to be up to date and all recordings must be present.

Aha, i completely missunderstood this feature in it's present form. It has nothing to do with preventing RS from recording reruns. The autosearch compares with recordings Db and it's purpose seem to be this one:

If for example i wanna record Top gear airing at channel 9 once a week (one rerun some days later) and channel 5 has Top gear Australia also airing once a week (3 reruns some days later). If setting up a searchpreset for Top gear the show i wanna have, the autosearch creates recording timers for both Top gear and Top gear Australia because of their similar names/titles, plus 4 additional timers for the reruns. This feature makes it possible to avoid recording Top gear Australia all together, by setting up a "blocking" searchpreset like this:

Name: gear Australia

Check "Add to Auto-Record search"

Check "Title"

 

So we now have one searchpreset for recording the Top gear show and an another blocking the Top gear Australia show.

When activating the autosearch, it is enough having only one entry of the Top gear Australia show in the recordings Db, in order to deactivate all new timers created with the title Top gear Australia...and all timers titled Top gear will be activated timers and will be recorded, unfortunately the rerun for Top gear too. This feature will be good to have and will be used now and then, but the feature we are after is to be abled to deactivate all those reruns many channels keep throwing at us. If a prevent rerun feature would be made and having the possibility to deactivate existing timers and not only new ones will make it awesome :bye:

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

Wow, i got the "Event" feature to work! The prevent recording of reruns actually works :thumbsup:

Thing is i can't understand why i didn't get it to work before...tested many different ways back and forth several times but everything failed. Today i got it to work.

I have changed format many times with the XEPG Format Editor and experimented with different TV grabbers and EPG sources, maybe that gave me no consistency in the recordings database entries and things failed accordingly.

 

Here is the working setup:

 

- A TV grabber using the xmltv format is needed along with the latest XEPG with the EPG Format Editor.

 

- In XEPG Format Editor set the Episode (onscreen) or if you are using Episode (xmltv_ns) under StartOfSubtitle. This StartOfSubtitle is the same as Event in RS. The episode information will be placed in the Subtitle/Event in your RS EPG. For me it looks like this: S07E12/15

This means season 7 episode 12 out of 15 episodes.

OBSERVE!! Important to disable your provider EPG update in RS (and in DVBViewer also), cuz if not the provider EPG information will overwrite the xmltv information and preventing reruns will fail.

 

- An optional tip is when installing RS check the "install the recording properties for Windows Explorer". Then you can see the recording properties when moving mouse cursor over file in the explorer. If using PropCopy this is needed.

 

- Always have "Save EPG as fileinfo" checked in both RS and DVBViewer. This creates a metadata tag with the episode info which the autosearch is dependant on to get "Event" feature to work. Check all other EPG info and loggings options as well.

 

- Bring up the old SearchPreset and then check the "Rec.Title" and "Rec.Event" box and save.

 

- Today i've recorded Hell's kitchen - S07E12/15, so the recording database contains this entry already. A rerun of this show will be airing 01:30 tonight. When executing the Autotimer this show now gets deactivated and NOT recorded. Yihaa...truly nice work Lars :lol:

 

The only bummer is this feature only deactivates new recording timers which is created by the autosearch. Already created recording timers created with earlier autosearches won't get deactivated. This means, for best result, the autosearch has to be executed several times every day, since often it's merely hours between first broadcast of show to the rerun. If the first show doesn't exist in the recording database when the autosearch gets executed, the rerun will not be deactivated.

 

So, we'll see if our great developer could whip up something to handle that :D

:bye:

Edited by majstang
Link to comment

I stumbled upon two very peculiar issues i can't get my head around. With the new feature in RS where the Autosearch compare it's EPGsearch findings to existing recording database entries. If there are matching entries in Db these recording timers will be deactivated. Now, if using the season/episode info in Event, all reruns of shows already in the recordings Db, will be deactivated. To get this to work i did notice "Save EPG as fileinfo" has to be used in RS. The Autosearch seem to rely upon the property/metadata line "Info" where the season/episode info resides in the .ts recording, when searching for matches in the Db. If the .ts stored in the recording database lacks this metadata, the autoseach fails to find this entry.

 

Now, peculiar things start to happen when creating a spacesaving "dummy".ts used for mimicing the original full sized recording in recording Db. In order to get the Autosearch to find this "dummy".ts, the only way is by copying the properties (with PropCopy) from the source file .ts to the destination file "dummy".ts and then delete the source.ts. Then Autosearch "Event" works using the "dummy".ts and recording timer get deactivated. However if using the two other methods available to migrate properties/metadata from EPGinformation.txt to destination file "dummy".ts, fails miserably. First method is by using RS Recording Editor (in webinterface->recordings). Bringing up the "dummy".ts entry in the editor and then check "File Info" box and hit save...this updates the metadata in "dummy".ts from the EPG information file .txt. Starting the Autoseach "Event" it fails to find the metadata just added to the .ts. Same result if using the tool "Delprops" which operates the same way as the recording editor.

 

Now why is this? Howcome only using PropCopy works? What exactly differs in the metadata if copied direct from the source.ts file or copied from the EPG information file .txt?? ALL my entries ive saved in the recording database are now useless, cuz all source.ts are already deleted.

 

Next issue is a database fileinfo refresh bug. This one made the testing to a complete nightmare. It seems the recording database has issues refreshing/updating when changes are done upon the metadata/properties on .ts entries. I'm forced to stop RS/delete SvcDatabase/start RS/refresh Db to make changes in the metadata/properties on "dummy".ts to stick.

Edited by majstang
Link to comment
Changes 1.9 Beta

Add: Autosearch: All recordings are now additionally added to the recordings history database. The entries will not be deleted, if you delete the actual recording. The check for previous recordings function of the auto recording timers now checks the search results against this database.

On every usage of the "Cleanup and Refresh Recording DB" task missing entries of existing recordings are added automatically to the history db.

Add: New task: Delete recording history.

Wow, these are pretty solid changes. Both issues i had problems with in the post above are now gone. Thanks for a work well done :)

 

However i found a small bug which gets large consequences in a certain scenario that would be great if it could be adressed in next beta.

When using this "dummy".ts backup script http://www.DVBViewer.tv/forum/topic/45486-automatically-delete-recordings-older-than-x-days/page__view__findpost__p__341750

the .log, .txt and "dummy".ts gets automatically created/backed up to a subfolder of the RS recording folder, executed by a RS after recording task. The actual recording will not get deleted until it is watched, so this one still remains in the RS recording folder. Now what happens when Refreshing Recording DB is i get duplicate entries for this show, which is totally expected. One for the actual recording and one for the "dummy".ts. This is generally no problem, cuz when the actual recording gets deleted eventually the duplicate entry disappears upon a Refresh Recording DB. In the normal user scenario these duplicate entries in recording DB is not problematic for the functionality of "The check for previous recordings function", since RS already updated the recordings history database exactly when the actual recording finished.

 

The problem occurs if Clearing Recording History. Now when the recording database has duplicate entries of the very same recording when doing a Refresh Recording DB, RS gets confused and NONE of these entries gets added to the recordings history database at all and "The check for previous recordings function" consequently fails. If moving the actual recording away from RS recording folder or delete it and then doing a Refresh Recording DB, the duplicate entry in recordings database gets removed and the remaining recording DB entry shows up in the recordings history database alright. So, the SQLite copyfunction seems not to have been conditioned for this case, cuz it doesn't know which one to pick for copy when there is duplicate source entries.

Edited by majstang
Link to comment
  • 1 month later...

Sorted in 1.9.1 :thumbsup: Many thanks :D

One small notice was if recording database has duplicate source entries these new entries, after Clearing Recording History in the recordings history database, takes "idRecord" 1 position and so on when refreshing database. Usually the oldest recording entries are on top. Could be a bit confusing when breaking the chronological order since "dateadded" is very hard to read. This little fact shouldn't affect the functionality of the check for recordings function though, so it's a minor detail. Sorry, i don't mean to be excessively meticulous :closed:

Link to comment
  • 4 weeks later...

Hello,

 

Add: Autosearch: All recordings are now additionally added to the recordings history database. The entries will not be deleted, if you delete the actual recording. The check for previous recordings function of the auto recording timers now checks the search results against this database.

On every usage of the “Cleanup and Refresh Recording DB“ task missing entries of existing recordings are added automatically to the history db.

 

How can I manually verify what recordings are in history db?

EDIT: I found it, recordedlist table in SvcDatabase.db3 ..

 

Add: EPG Search: The auto timer search can check new timers additionally against existing timers.

It compares the automatically generated timer names against the new one. This only works for programs which do create a unique timer name The timer name is generated from the EPG title and the first 50 chars of the EPG event.

 

How does this exactly work? If I use autotimer for 7d EPG, during that process it seems to add two enabled timers for same event (1 original run, 1 rerun - both already present in EPG). Both have same title and event names. I thought this would not add timer for the rerun, just for the original run. Even if I manually delete rerun timer, so only original run timer exists, next autotimer adds active timer of that rerun again.

 

The timer check seems to work for recordings present in DB, but not against EPG events. Am I doing something wrong?

 

Thanks for info.

Edited by jakub
Link to comment
×
×
  • Create New...