Re: [vdr] Recordings Numbering
Udo Richter wrote: Am 09.11.2010 16:35, schrieb Matthias Wächter: You just re-introduce the old problem. Don't ever re-number. If you don't renumber any SVDRP client can be safe in assuming for (nearly) any time span to mean the same recording as the server when it updates a recording's schedule. In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? Don't recordings actually already have a unique id? It's the name of the directory they are stored in. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPGSearch doesn't avoid repeats anymore?
On 10/11/10 09:09, Teemu Suikki wrote: Why doesn't it match? The descriptions are 100% identical. Check your search timer's configuration for comparing 'sub-title' when avoiding repeats. Compare subtitle should be set to either 'No' or 'If present', otherwise the comparison will also return false if your EPG doesn't contain a subtitle for the entry. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] EPGSearch doesn't avoid repeats anymore?
Hi, I recently updated my VDR from 1.4.5 to 1.7.15, and also updated all plugins to their latest version. EPGSearch is epgsearch-0.9.25.beta17. Everything works, but epgsearch doesn't avoid repeats anymore! Here's an example from the file epgsearchdone.data: R 1266873900 1800 0 C T-8438-8193-65 T Frasier D Kevyt-Frasier. KACL haastaa kilpailevan KPXY-aseman painonpudotuskisaan, ja vastapuolen tiimissE4 on Frasierin lukioaikainen koulukiusaaja. Niles ja Martin puolestaan hoivaavat ikkunaan tF6rmE4nnyttE4 lintua. Amerikkalainen komediasarja. 11. @ epgsearchchannel4 - Nelonen/channelsearchtimerFrasier/searchtimerstart1266873600/startstop1266876300/stops-id0/s-ideventid436/eventid/epgsearch r - some time later R 1289337600 1800 0 C T-8438-8193-65 T Frasier D Kevyt-Frasier. KACL haastaa kilpailevan KPXY-aseman painonpudotuskisaan, ja vastapuolen tiimissE4 on Frasierin lukioaikainen koulukiusaaja. Niles ja Martin puolestaan hoivaavat ikkunaan tF6rmE4nnyttE4 lintua. Amerikkalainen komediasarja. 11. @ epgsearchchannel4 - Nelonen/channelsearchtimerFrasier/searchtimerstart1289337300/startstop128934/stops-id0/s-ideventid11873/eventid/epgsearch r - Why doesn't it match? The descriptions are 100% identical. -- Teemu Suikki http://www.z-power.fi/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
2010/11/10 Ludwig Nussel ludwig.nus...@suse.de: Udo Richter wrote: Am 09.11.2010 16:35, schrieb Matthias Wächter: You just re-introduce the old problem. Don't ever re-number. If you don't renumber any SVDRP client can be safe in assuming for (nearly) any time span to mean the same recording as the server when it updates a recording's schedule. In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? Don't recordings actually already have a unique id? It's the name of the directory they are stored in. ACK, keep it simple ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On Tue, 09 Nov 2010 23:33:05 +0100, Udo Richter wrote In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? The VDR instance ID (commandline option -i) should become part of the recordings ID. If the instance ID is not 0, we would then get large numbers (InstanceID n | recordingNumber) or we need a separator (%d-%d). The instance ID is part of the filename. So for recordings of a friend, you should use a dedicated instance ID in the filename (something users probably will forget). An other problem to solve: old recordings will need an ID, too. And VDR will not always be able to update info.vdr (e.g. recording on a DVD). Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On 11/10/10 10:38, Frank Schmirler wrote: On Tue, 09 Nov 2010 23:33:05 +0100, Udo Richter wrote In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? The VDR instance ID (commandline option -i) should become part of the recordings ID. If the instance ID is not 0, we would then get large numbers (InstanceID n | recordingNumber) or we need a separator (%d-%d). The instance ID is part of the filename. So for recordings of a friend, you should use a dedicated instance ID in the filename (something users probably will forget). An other problem to solve: old recordings will need an ID, too. And VDR will not always be able to update info.vdr (e.g. recording on a DVD). Hey, hey, guys, get a grip! Let's not make this rocket science ;-) The question at hand is whether the *number* used in the LSTR and LSTT command listings to identify a particular recording or timer, respectively, shall always start at 1 and count up, and be renumbered whenever an item is newly created ot deleted. Or whether that number shall simply count up and never be renumbered (as long as this instance of VDR lives). Anything beyond this is against the KISS principle ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On Wed, 10 Nov 2010 10:44:59 +0100, Klaus Schmidinger wrote The question at hand is whether the *number* used in the LSTR and LSTT command listings to identify a particular recording or timer, respectively, shall always start at 1 and count up, and be renumbered whenever an item is newly created ot deleted. Or whether that number shall simply count up and never be renumbered (as long as this instance of VDR lives). Anything beyond this is against the KISS principle ;-) ACK. Unique IDs over the lifetime of an SVDRP connection solve the actual problem. Everything beyond get's too complicated. Guess a touch /video/.update would result in new IDs for all recordings. So one must be aware that if an ID is no longer available, the corresponding item has not necessarily been deleted. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPGSearch doesn't avoid repeats anymore?
On 10/11/10 12:05, Teemu Suikki wrote: I think there is a bug in epgsearch.. See epgsearchtools.c line 806: if ((!compareTitle || Title1 == Title2) (!compareSubtitle || (Subtitle1 == Subtitle2 (compareSubtitle==2 || Subtitle1!= I don't really understand the last check. Perhaps there should be == instead of != or something? I don't think its a bug, it seems to be the intended function. 1) First it checks that we either said 'don't compare the title' or the titles match (!compareTitle || Title1 == Title2) 2a) Then it ANDs this with a check that either we said 'don't compare the subtitle' (!compareSubtitle) OR the subtitles match (Subtitle1 == Subtitle2) AND also we've either said 'only if present' (compareSubtitle==2) OR at least one of the sub-titles is non-empty (Subtitle1!=) I just don't know why its a useful function :-) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPGSearch doesn't avoid repeats anymore?
Check your search timer's configuration for comparing 'sub-title' when
avoiding repeats. Compare subtitle should be set to either 'No' or 'If
present', otherwise the comparison will also return false if your EPG
doesn't contain a subtitle for the entry.
Hey, that was it! Thanks a bunch. :)
No problem :-)
Tbh I'm not sure why the 'Yes' option is available as a choice. Why would
you ever want to go through this logic path?
// pseudo code, compare 'this' recording to 'other' recording for equality
when searchtimer 'compare sub-title' option is set to 'yes'
boolean equals(Recording other) {
if (this.subtitle == null || other.subtitle == null) {
return false;
}
Yeah, weird. What's more, VDRadmin only has yes/no choices there..
Could be that I don't have the latest version, though. Anyway it makes
no sense to me to have separate if present and yes options. What's
the point in comparing non-existent subtitles, especially if the
comparison always fails?
I think there is a bug in epgsearch.. See epgsearchtools.c line 806:
if ((!compareTitle || Title1 == Title2)
(!compareSubtitle || (Subtitle1 == Subtitle2
(compareSubtitle==2 || Subtitle1!=
I don't really understand the last check. Perhaps there should be ==
instead of != or something?
--
Teemu Suikki
http://www.z-power.fi/
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPGSearch doesn't avoid repeats anymore?
2010/11/10 Dominic Evans oldma...@gmail.com: On 10/11/10 09:09, Teemu Suikki wrote: Why doesn't it match? The descriptions are 100% identical. Check your search timer's configuration for comparing 'sub-title' when avoiding repeats. Compare subtitle should be set to either 'No' or 'If present', otherwise the comparison will also return false if your EPG doesn't contain a subtitle for the entry. Hey, that was it! Thanks a bunch. :) -- Teemu Suikki http://www.z-power.fi/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPGSearch doesn't avoid repeats anymore?
On 10/11/10 10:09, Teemu Suikki wrote:
2010/11/10 Dominic Evansoldma...@gmail.com:
On 10/11/10 09:09, Teemu Suikki wrote:
Why doesn't it match? The descriptions are 100% identical.
Check your search timer's configuration for comparing 'sub-title' when
avoiding repeats. Compare subtitle should be set to either 'No' or 'If
present', otherwise the comparison will also return false if your EPG
doesn't contain a subtitle for the entry.
Hey, that was it! Thanks a bunch. :)
No problem :-)
Tbh I'm not sure why the 'Yes' option is available as a choice. Why
would you ever want to go through this logic path?
// pseudo code, compare 'this' recording to 'other' recording for
equality when searchtimer 'compare sub-title' option is set to 'yes'
boolean equals(Recording other) {
if (this.subtitle == null || other.subtitle == null) {
return false;
}
...
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPGSearch doesn't avoid repeats anymore?
On 10/11/10 13:25, Dominic Evans wrote: I don't think its a bug, it seems to be the intended function. 1) First it checks that we either said 'don't compare the title' or the titles match (!compareTitle || Title1 == Title2) 2a) Then it ANDs this with a check that either we said 'don't compare the subtitle' (!compareSubtitle) OR the subtitles match (Subtitle1 == Subtitle2) AND also we've either said 'only if present' (compareSubtitle==2) OR at least one of the sub-titles is non-empty (Subtitle1!=) I just don't know why its a useful function :-) I did a bit more digging and discovered this was a new option since 0.9.25.beta7 and is listed in the HISTORY as: Avoid repeats: 'Compare subtitle' has now a third value 'if present' besides 'no' and 'yes'. With this setting epgsearch will classify two events only as equal if their episode names match and are not empty. Caution: if your EPG data has no episode names for different episodes don't use this option! 'yes' will then be the better choice even if this results in double recordings. I think the description here is incorrect though. epgsearch will classify two events only as equal if their episode names match and are not empty seems to be the behaviour when this option is set to 'yes', not when it is set to the new 'if present' third value. The last sentence also seems to be incorrect. 'if-present' is the optimal choice if your EPG data doesn't always have episode names, using them for the comparison if they're present, ignoring them if they're missing. For anyone interested, I've attached the git-diff of 53677636 (when this was introduced). 53677636.patch.gz Description: GNU Zip compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPGSearch doesn't avoid repeats anymore?
2010/11/10 Dominic Evans oldma...@gmail.com: I did a bit more digging and discovered this was a new option since 0.9.25.beta7 and is listed in the HISTORY as: Avoid repeats: 'Compare subtitle' has now a third value 'if present' besides 'no' and 'yes'. With this setting epgsearch will classify two events only as equal if their episode names match and are not empty. Caution: if your EPG data has no episode names for different episodes don't use this option! 'yes' will then be the better choice even if this results in double recordings. It would seem that yes and if present settings should be swapped? I'm pretty sure yes worked like if present earlier, because my timers worked just fine before upgrading.. -- Teemu Suikki http://www.z-power.fi/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
Hi, Am Mittwoch, den 10.11.2010, 12:23 +0100 schrieb Frank Schmirler: ACK. Unique IDs over the lifetime of an SVDRP connection solve the actual problem. Everything beyond get's too complicated. Here I would agree with you. Guess a touch /video/.update would result in new IDs for all recordings. So one must be aware that if an ID is no longer available, the corresponding item has not necessarily been deleted. Why ? This is not even necessary ! Missing recordings should simple remove from list (LSTR) and new recordings should added at end of list. Anything else would not work with existing svdrp programs. But right now VDR can use only one connection at same time. From my point of view (xxv as svdrp client), I would not block the connection permanent. And I do not would to reread every time any recordings. Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On Wed, 10 Nov 2010 19:09:46 +0100 Andreas Brachold m...@deltab.de wrote: Hi, Am Mittwoch, den 10.11.2010, 12:23 +0100 schrieb Frank Schmirler: ACK. Unique IDs over the lifetime of an SVDRP connection solve the actual problem. Everything beyond get's too complicated. Here I would agree with you. Guess a touch /video/.update would result in new IDs for all recordings. So one must be aware that if an ID is no longer available, the corresponding item has not necessarily been deleted. Why ? This is not even necessary ! Missing recordings should simple remove from list (LSTR) and new recordings should added at end of list. Anything else would not work with existing svdrp programs. But right now VDR can use only one connection at same time. From my point of view (xxv as svdrp client), I would not block the connection permanent. And I do not would to reread every time any recordings. So the problem is not the recording numbering (for what ?) , but the svdrp limitation to one connection. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPGSearch doesn't avoid repeats anymore?
Hi,
well, the intended behaviour was:
setting 'if present': two events match if both have non empty episode
names that match. If not, the events are handled as different, resulting
in more eventually double recordings.
setting 'Yes': the match is achieved if the episode names match, also if
both are empty. If the provider delivers no episode names for two
different events, just one would be recorded.
IMHO, it seems the code should actually look like this:
if ((!compareTitle || Title1 == Title2)
(!compareSubtitle || (Subtitle1 == Subtitle2
(compareSubtitle==1 || Subtitle1!=
please note the compareSubtitle==1 ('Yes') instead of
compareSubtitle==2 ('If present').
BTW, this was the code of my first commit on 2008-12-03, that I
'corrected' for any reason to the current code on the same day:
http://projects.vdr-developer.org/git/?p=vdr-plugin-epgsearch.git;a=history;f=epgsearchtools.c;h=71a83a19c1bd4c89aa0c0c2808d216e30b03ca34;hb=ba87be9b2650796a507249c098eca815bff9b5e5
The documentation should also be fixed to:
...Caution: if your EPG data has no episode names for different episodes
don't use option 'yes'! 'if present' will then be the better choice even
if this
results in double recordings.
Probably it would be the best solution to drop the 'Yes' setting.
BR,
Christian
Am 10.11.2010 14:43, schrieb Dominic Evans:
On 10/11/10 13:25, Dominic Evans wrote:
I don't think its a bug, it seems to be the intended function.
1) First it checks that we either said 'don't compare the title' or the
titles match (!compareTitle || Title1 == Title2)
2a) Then it ANDs this with a check that either we said 'don't compare
the subtitle' (!compareSubtitle) OR the subtitles match (Subtitle1 ==
Subtitle2) AND also we've either said 'only if present'
(compareSubtitle==2) OR at least one of the sub-titles is non-empty
(Subtitle1!=)
I just don't know why its a useful function :-)
I did a bit more digging and discovered this was a new option since
0.9.25.beta7 and is listed in the HISTORY as:
Avoid repeats: 'Compare subtitle' has now a third value 'if present'
besides 'no' and 'yes'. With this setting epgsearch will classify two
events only as equal if their episode names match and are not empty.
Caution: if your EPG data has no episode names for different episodes
don't use this option! 'yes' will then be the better choice even if this
results in double recordings.
I think the description here is incorrect though. epgsearch will
classify two events only as equal if their episode names match and are
not empty seems to be the behaviour when this option is set to 'yes',
not when it is set to the new 'if present' third value. The last
sentence also seems to be incorrect. 'if-present' is the optimal
choice if your EPG data doesn't always have episode names, using them
for the comparison if they're present, ignoring them if they're missing.
For anyone interested, I've attached the git-diff of 53677636 (when
this was introduced).
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-lib and vaapi support
I demand that lucian orasanu may or may not have written... how about moving to mplayer instead of xine-lib, is not maintained very well any more? Feel free to help out, by all means... -- | Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon | using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back! | + Lobby friends, family, business, government.WE'RE KILLING THE PLANET. The moon is made of green cheese. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-lib and vaapi support
I demand that Tony Houghton may or may not have written... On 08/11/10 12:50, Theunis Potgieter wrote: [snip] You can tell mplayer the exact ratio of your monitor and the exact ratio of the video on the command line and it correctly calculates how to display it. vdr-sxfe and vdr-fbfe have an equivalent of -monitoraspect but xine-ui and gxine don't, or didn't last time I looked. gxine has video.display_width and video.display_height. I should move them to xine-lib one day... [snip] -- | Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon | using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back! | Let's keep the pound sterling That must be wonderful! I don't understand it at all. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
