Some (external) applications require a way of uniquely identifying timers. Currently some of these use the upper 16 bit of the 'flags' field, while others use the 'summary' field. In an effort to make things more straightforward (and simpler, from VDR's point of view ;-) I propose the following changes:
- The 'summary' field in the timer definition becomes a pure string parameter, into which (external) applications can write whatever they like. VDR will read and write it, but otherwise won't do anything with it. The name of this field would be changed to something like 'aux' or so.
- The description of a recording is taken exclusively from its related EPG data. If an application wants to use a different description it would have to set it with SVDRP/PUTE and use table ID 0x00, so that it won't be overwritten (as a side effect, however, this would also disable VPS for such an event). An added bonus of this method would be that not only the 'description' can be set, but also 'title' and 'short text'.
- The upper 16 bit of the timer's 'flag' field are no longer given any special treatment, and also shouldn't be used. Only the flags defined in vdr.5 shall be used.
- The cEvent::eventID is changed to u_int32_t so that fake event ids won't collide with real ones (by using values greater than 0xFFFF).
- The 'E' record of the recording's EPG data will also be written into 'info.vdr'.
- A new record in 'info.vdr' will hold the 'aux' string of the timer that created this recording.
If we can agree on these changes until next weekend, I would incorporate them into the upcoming version 1.4.
Klaus
Hi,
Am Montag, den 20.02.2006, 17:42 +0100 schrieb Klaus Schmidinger:
Some (external) applications require a way of uniquely identifying timers. Currently some of these use the upper 16 bit of the 'flags' field, while others use the 'summary' field. In an effort to make things more straightforward (and simpler, from VDR's point of view ;-) I propose the following changes: ...
Sounds interesting, and could some presentation problems inside xxv solve.
Only the lost of VPS, after editing description of timer, make me a little bit unhappy ...
Cu, Andreas
I demand that Klaus Schmidinger may or may not have written...
[snip]
If we can agree on these changes until next weekend,
Until? Are you sure? :-)
[snip]
Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
[snip]
If we can agree on these changes until next weekend,
Until? Are you sure? :-)
Well, I guess that's another one of those fine subtleties in the English language that I, not being a native speaker, am not aware of (like "lose" and "loose") ;-)
Maybe I should have written "...by next weekend"?
Klaus
I demand that Klaus Schmidinger may or may not have written...
Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written... [snip]
If we can agree on these changes until next weekend,
Until? Are you sure? :-)
Well, I guess that's another one of those fine subtleties in the English language that I, not being a native speaker, am not aware of (like "lose" and "loose") ;-)
Be careful with that. It'll be "were" and "where" next ;-)
Maybe I should have written "...by next weekend"?
"By" or "before", yes. Consider "valid until next weekend", "validated before next weekend".
Klaus Schmidinger wrote:
- The upper 16 bit of the timer's 'flag' field are no longer given any special treatment, and also shouldn't be used. Only the flags defined in vdr.5 shall be used.
I am using a script I wrote to add and manage my timers automatically. The script is using these upper 16 bits to identify which timers have been added by the script and which have been added or changed manually. This is done by setting an id (magic number) in these upper 16 bits. Later, only timers which have this id are touched (modified) by the script.
The thing I like is the fact that (from vdr.5) "When a user modifies an active timer, the upper 16 bits of this unsigned 32 bit parameter will be explicitly set to 0." Because of this, my script doesn't overwrite manual changes of the timers.
How can this be achieved in your new concept? (Any positive answer is ok for me - it is no problem to change my script.)
Dirk
Dirk wrote:
Klaus Schmidinger wrote:
- The upper 16 bit of the timer's 'flag' field are no longer
given any special treatment, and also shouldn't be used. Only the flags defined in vdr.5 shall be used.
I am using a script I wrote to add and manage my timers automatically. The script is using these upper 16 bits to identify which timers have been added by the script and which have been added or changed manually. This is done by setting an id (magic number) in these upper 16 bits. Later, only timers which have this id are touched (modified) by the script.
The thing I like is the fact that (from vdr.5) "When a user modifies an active timer, the upper 16 bits of this unsigned 32 bit parameter will be explicitly set to 0." Because of this, my script doesn't overwrite manual changes of the timers.
How can this be achieved in your new concept? (Any positive answer is ok for me - it is no problem to change my script.)
I guess the logical thing to do then would be to clear the "aux" field in that case.
Klaus
Klaus Schmidinger wrote:
Dirk wrote:
Klaus Schmidinger wrote:
- The upper 16 bit of the timer's 'flag' field are no longer
given any special treatment, and also shouldn't be used. Only the flags defined in vdr.5 shall be used.
I am using a script I wrote to add and manage my timers automatically. The script is using these upper 16 bits to identify which timers have been added by the script and which have been added or changed manually. This is done by setting an id (magic number) in these upper 16 bits. Later, only timers which have this id are touched (modified) by the script.
The thing I like is the fact that (from vdr.5) "When a user modifies an active timer, the upper 16 bits of this unsigned 32 bit parameter will be explicitly set to 0." Because of this, my script doesn't overwrite manual changes of the timers.
How can this be achieved in your new concept? (Any positive answer is ok for me - it is no problem to change my script.)
I guess the logical thing to do then would be to clear the "aux" field in that case.
I'm definitly against that. That would COMPLETLY destroy Master-Timer funktionality!
Not only that it couldn't find it's timers anymore, to propagate EPG-Changes for e.g. The timers would look like complete "User defined timers" which Master-Timer completely ignores (Not only "User changed" like before!)
For e.g. for the "done" functionality it searches the info.vdr for it's signature which would have been totally destroyed.
And addionally Master-Timer can't rely on VDR putting the right(tm) EPG-Data into the info.vdr (Without strong binding between timers and EPG it's only 99% "safe" or IOW unusable), so i still have to put all the data Master-Timer needs into the "AUX"-Field.
So i'm definitly against VDR doing anything more than storing the AUX field.
As i said in the other mail, with a little more added logic a script can find out itself if a timers was modified. You only loose the ability to just to mark the timer as "modified" via "show and store" the timer in OSD(*?) as that wouldn't change the timer. But if you change the Prio or lifetime by 1 the timer would clearly not be in "original" state.
I myself change the start & end times frequently (via SVDR so this all doesn't apply to me in the first place) and i didn't want to loose the binding just because i had to change the margins to solve conflicts between different timers.
*: Was is sufficient to just show and store the timer to clear the flag? If not, then you are in the same situation as before: you have to "really" change something before VDR clears the flag
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
Dirk wrote:
Klaus Schmidinger wrote:
- The upper 16 bit of the timer's 'flag' field are no longer
given any special treatment, and also shouldn't be used. Only the flags defined in vdr.5 shall be used.
I am using a script I wrote to add and manage my timers automatically. The script is using these upper 16 bits to identify which timers have been added by the script and which have been added or changed manually. This is done by setting an id (magic number) in these upper 16 bits. Later, only timers which have this id are touched (modified) by the script.
The thing I like is the fact that (from vdr.5) "When a user modifies an active timer, the upper 16 bits of this unsigned 32 bit parameter will be explicitly set to 0." Because of this, my script doesn't overwrite manual changes of the timers.
How can this be achieved in your new concept? (Any positive answer is ok for me - it is no problem to change my script.)
I guess the logical thing to do then would be to clear the "aux" field in that case.
I'm definitly against that. That would COMPLETLY destroy Master-Timer funktionality!
Not only that it couldn't find it's timers anymore, to propagate EPG-Changes for e.g. The timers would look like complete "User defined timers" which Master-Timer completely ignores (Not only "User changed" like before!)
For e.g. for the "done" functionality it searches the info.vdr for it's signature which would have been totally destroyed.
And addionally Master-Timer can't rely on VDR putting the right(tm) EPG-Data into the info.vdr (Without strong binding between timers and EPG it's only 99% "safe" or IOW unusable), so i still have to put all the data Master-Timer needs into the "AUX"-Field.
So i'm definitly against VDR doing anything more than storing the AUX field.
As i said in the other mail, with a little more added logic a script can find out itself if a timers was modified. You only loose the ability to just to mark the timer as "modified" via "show and store" the timer in OSD(*?) as that wouldn't change the timer. But if you change the Prio or lifetime by 1 the timer would clearly not be in "original" state.
I myself change the start & end times frequently (via SVDR so this all doesn't apply to me in the first place) and i didn't want to loose the binding just because i had to change the margins to solve conflicts between different timers.
*: Was is sufficient to just show and store the timer to clear the flag? If not, then you are in the same situation as before: you have to "really" change something before VDR clears the flag
You need to actually change the timer in the "Edit timer" menu to have these flags reset.
How about we define
tfModified = 0x8000
which will be _set_ whenever the user modifies a timer. That way an external program can detect that the user has made a modification, and the "aux" field can be left untouched.
Currently the upper 16 bit are only reset if the user presses Ok in the "Edit timer" menu (after a change). If he presses Blue in the "Timers" menu (to (temporarily) disable a timer) these flags are _not_ reset. Should this behavior remain the same when (if) switching to tfModified?
Klaus
Klaus Schmidinger wrote:
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
Dirk wrote:
Klaus Schmidinger wrote:
- The upper 16 bit of the timer's 'flag' field are no longer
given any special treatment, and also shouldn't be used. Only the flags defined in vdr.5 shall be used.
I am using a script I wrote to add and manage my timers automatically. The script is using these upper 16 bits to identify which timers have been added by the script and which have been added or changed manually. This is done by setting an id (magic number) in these upper 16 bits. Later, only timers which have this id are touched (modified) by the script.
The thing I like is the fact that (from vdr.5) "When a user modifies an active timer, the upper 16 bits of this unsigned 32 bit parameter will be explicitly set to 0." Because of this, my script doesn't overwrite manual changes of the timers.
How can this be achieved in your new concept? (Any positive answer is ok for me - it is no problem to change my script.)
I guess the logical thing to do then would be to clear the "aux" field in that case.
I'm definitly against that. That would COMPLETLY destroy Master-Timer funktionality!
Not only that it couldn't find it's timers anymore, to propagate EPG-Changes for e.g. The timers would look like complete "User defined timers" which Master-Timer completely ignores (Not only "User changed" like before!)
For e.g. for the "done" functionality it searches the info.vdr for it's signature which would have been totally destroyed.
And addionally Master-Timer can't rely on VDR putting the right(tm) EPG-Data into the info.vdr (Without strong binding between timers and EPG it's only 99% "safe" or IOW unusable), so i still have to put all the data Master-Timer needs into the "AUX"-Field.
So i'm definitly against VDR doing anything more than storing the AUX field.
As i said in the other mail, with a little more added logic a script can find out itself if a timers was modified. You only loose the ability to just to mark the timer as "modified" via "show and store" the timer in OSD(*?) as that wouldn't change the timer. But if you change the Prio or lifetime by 1 the timer would clearly not be in "original" state.
I myself change the start & end times frequently (via SVDR so this all doesn't apply to me in the first place) and i didn't want to loose the binding just because i had to change the margins to solve conflicts between different timers.
*: Was is sufficient to just show and store the timer to clear the flag? If not, then you are in the same situation as before: you have to "really" change something before VDR clears the flag
You need to actually change the timer in the "Edit timer" menu to have these flags reset.
How about we define
tfModified = 0x8000
IOW Bit 31?
But why don't you use the "next free bit" and change the description to
"Timer modified via OSD after creation" as any other modification isn't caught by VDR and can be even reseted externally.
which will be _set_ whenever the user modifies a timer. That way an external program can detect that the user has made a modification, and the "aux" field can be left untouched.
Currently the upper 16 bit are only reset if the user presses Ok in the "Edit timer" menu (after a change). If he presses Blue in the "Timers" menu (to (temporarily) disable a timer) these flags are _not_ reset. Should this behavior remain the same when (if) switching to tfModified?
Speaking for myself (Master-Timer) i can say i can live with a flag. As i can freely ignore it. :-)
As long as you don't wreak havoc with the AUX-field i'm happy. :-)
In the end that wholeexercise is a bit pointless because you can still modify a timer via SVDR(*) without setting the flag as you always modify the whole timer entry and not singular componets of a timer.
*: IOW if you use VDRAdmin, XXV etc to modify timers you have already lost. So i'd say there's a not so small percentage of cases where this whole schema simply won't work.
Bis denn
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
Dirk wrote:
Klaus Schmidinger wrote:
- The upper 16 bit of the timer's 'flag' field are no longer
given any special treatment, and also shouldn't be used. Only the flags defined in vdr.5 shall be used.
I am using a script I wrote to add and manage my timers automatically. The script is using these upper 16 bits to identify which timers have been added by the script and which have been added or changed manually. This is done by setting an id (magic number) in these upper 16 bits. Later, only timers which have this id are touched (modified) by the script.
The thing I like is the fact that (from vdr.5) "When a user modifies an active timer, the upper 16 bits of this unsigned 32 bit parameter will be explicitly set to 0." Because of this, my script doesn't overwrite manual changes of the timers.
How can this be achieved in your new concept? (Any positive answer is ok for me - it is no problem to change my script.)
I guess the logical thing to do then would be to clear the "aux" field in that case.
I'm definitly against that. That would COMPLETLY destroy Master-Timer funktionality!
Not only that it couldn't find it's timers anymore, to propagate EPG-Changes for e.g. The timers would look like complete "User defined timers" which Master-Timer completely ignores (Not only "User changed" like before!)
For e.g. for the "done" functionality it searches the info.vdr for it's signature which would have been totally destroyed.
And addionally Master-Timer can't rely on VDR putting the right(tm) EPG-Data into the info.vdr (Without strong binding between timers and EPG it's only 99% "safe" or IOW unusable), so i still have to put all the data Master-Timer needs into the "AUX"-Field.
So i'm definitly against VDR doing anything more than storing the AUX field.
As i said in the other mail, with a little more added logic a script can find out itself if a timers was modified. You only loose the ability to just to mark the timer as "modified" via "show and store" the timer in OSD(*?) as that wouldn't change the timer. But if you change the Prio or lifetime by 1 the timer would clearly not be in "original" state.
I myself change the start & end times frequently (via SVDR so this all doesn't apply to me in the first place) and i didn't want to loose the binding just because i had to change the margins to solve conflicts between different timers.
*: Was is sufficient to just show and store the timer to clear the flag? If not, then you are in the same situation as before: you have to "really" change something before VDR clears the flag
You need to actually change the timer in the "Edit timer" menu to have these flags reset.
How about we define
tfModified = 0x8000
IOW Bit 31?
But why don't you use the "next free bit" and change the description to
Because it's nothing VDR itself would need, so I thought I'd put it to the far end of the flag word ;-)
"Timer modified via OSD after creation" as any other modification isn't caught by VDR and can be even reseted externally.
Ok.
which will be _set_ whenever the user modifies a timer. That way an external program can detect that the user has made a modification, and the "aux" field can be left untouched.
Currently the upper 16 bit are only reset if the user presses Ok in the "Edit timer" menu (after a change). If he presses Blue in the "Timers" menu (to (temporarily) disable a timer) these flags are _not_ reset. Should this behavior remain the same when (if) switching to tfModified?
Speaking for myself (Master-Timer) i can say i can live with a flag. As i can freely ignore it. :-)
As long as you don't wreak havoc with the AUX-field i'm happy. :-)
In the end that wholeexercise is a bit pointless because you can still modify a timer via SVDR(*) without setting the flag as you always modify the whole timer entry and not singular componets of a timer.
*: IOW if you use VDRAdmin, XXV etc to modify timers you have already lost. So i'd say there's a not so small percentage of cases where this whole schema simply won't work.
If a user mixes different types of timer creation/handling, all kinds of things can happen. The applications would have to agree on certain rules to avoid that, but that's something the authors of those apps would have to discuss.
Klaus
Hi Klaus,
this change would also affect epgsearch and its 'search timers'. Since I don't use event ids, the changes would be small. But there is one thing, that will be lost with it: Timers created by epgsearch have additional information at the bottom of the description, like the channel from which the recording will be done or the search timer that was responsible for the timer. I think, VDRAdmin works the same way. After the recording is done this info was available til now in the recordings description. If I understood you right, this info should now be moved to the 'aux' field. Do you plan any way, to display the 'aux' value for timers and recordings in VDR's OSD?
BTW: if this change becomes true, it would be nice to have a pre-Patch to give the people, that are concerned with it, some time to prepare their stuff. I think some scripts/plugins will need heavy changes ;-)
Christian
Christian Wieninger wrote:
Hi Klaus,
this change would also affect epgsearch and its 'search timers'. Since I don't use event ids, the changes would be small. But there is one thing, that will be lost with it: Timers created by epgsearch have additional information at the bottom of the description, like the channel from which the recording will be done
The channel from which to record has always been part of the timer definition (the second field) - am I missing something?
or the search timer that was responsible for the timer. I think, VDRAdmin works the same way. After the recording is done this info was available til now in the recordings description. If I understood you right, this info should now be moved to the 'aux' field. Do you plan any way, to display the 'aux' value for timers and recordings in VDR's OSD?
The recorded channel is already stored in the 'C' record of the info.vdr file. If necessary, that information can be displayed in the cSkin::SetRecording() function. The actual "aux" value of a timer has no conceivable meaning to VDR, so there's no point in displaying it, I'd say.
BTW: if this change becomes true, it would be nice to have a pre-Patch to give the people, that are concerned with it, some time to prepare their stuff. I think some scripts/plugins will need heavy changes ;-)
Well, we're still in a development phase, so changes can be many and heavy. Since there are only two weekends left before CeBIT, and that's when I want to have at least a release candidate of version 1.4 ready, I'm afraid there's no time for pre-patches. However, since this thread is supposed to define exactly how things are going to be changed, you should be able to prepare your particular tool accordingly.
I'll add a remark to the release notes, telling people who use external tools for timer programming to wait until those tools have been adapted before using the next version of VDR (not that I have high hopes, though, that anybody will actually read it... ;-).
Klaus
Klaus Schmidinger wrote:
I'll add a remark to the release notes, telling people who use external tools for timer programming to wait until those tools have been adapted before using the next version of VDR (not that I have high hopes, though, that anybody will actually read it... ;-).
All i needed to release a compatible Master-Timer would be the name of the field you intend to put the AUX-Data in the info.vdr
Everything else stays practically the same (for now)
Bis denn
Hi,
Am Dienstag, 21. Februar 2006 22:14 schrieb Klaus Schmidinger:
The channel from which to record has always been part of the timer definition (the second field) - am I missing something?
sure, but this was the only way I knew to put this info also in the later recording summary.
The recorded channel is already stored in the 'C' record of the info.vdr file. If necessary, that information can be displayed in the cSkin::SetRecording() function. The actual "aux" value of a timer has no conceivable meaning to VDR, so there's no point in displaying it, I'd say.
ok, but is there any skin, that displays this info already? Atleast my info about the search timer, that triggered the timer/recording will not be visible anymore. What about an additional simple submenu in the summary menu of timers/recordings, e.g. called with the unused key 'blue' labeled 'Aux'.
Well, we're still in a development phase, so changes can be many and heavy.
I knew you would say this ;-) But most people use the development version as if it was already a release (it nearly is!) and if some addons don't work with it, they complain. But I agree with you, and with 1.4 things are getting simpler.
Since there are only two weekends left before CeBIT, and that's when I want to have at least a release candidate of version 1.4 ready, I'm afraid there's no time for pre-patches. However, since this thread is supposed to define exactly how things are going to be changed, you should be able to prepare your particular tool accordingly.
ok, so it's sure that this change will be made?
Christian
Christian Wieninger wrote:
Hi,
Am Dienstag, 21. Februar 2006 22:14 schrieb Klaus Schmidinger:
The channel from which to record has always been part of the timer definition (the second field) - am I missing something?
sure, but this was the only way I knew to put this info also in the later recording summary.
The recorded channel is already stored in the 'C' record of the info.vdr file. If necessary, that information can be displayed in the cSkin::SetRecording() function. The actual "aux" value of a timer has no conceivable meaning to VDR, so there's no point in displaying it, I'd say.
ok, but is there any skin, that displays this info already?
I wouldn't know.
Atleast my info about the search timer, that triggered the timer/recording will not be visible anymore. What about an additional simple submenu in the summary menu of timers/recordings, e.g. called with the unused key 'blue' labeled 'Aux'.
The 'aux' field shall be of no concern to VDR, so I don't see why there should be a button wasted to display it. What's so important about that information, anyway?
Well, we're still in a development phase, so changes can be many and heavy.
I knew you would say this ;-) But most people use the development version as if it was already a release (it nearly is!) and if some addons don't work with it, they complain. But I agree with you, and with 1.4 things are getting simpler.
Since there are only two weekends left before CeBIT, and that's when I want to have at least a release candidate of version 1.4 ready, I'm afraid there's no time for pre-patches. However, since this thread is supposed to define exactly how things are going to be changed, you should be able to prepare your particular tool accordingly.
ok, so it's sure that this change will be made?
AFAICS thre is still a "go" for this change.
Klaus
Klaus Schmidinger wrote:
Christian Wieninger wrote:
Atleast my info about the search timer, that triggered the timer/recording will not be visible anymore. What about an additional simple submenu in the summary menu of timers/recordings, e.g. called with the unused key 'blue' labeled 'Aux'.
The 'aux' field shall be of no concern to VDR, so I don't see why there should be a button wasted to display it. What's so important about that information, anyway?
It's of no use of VDR "itself" but like the title/subitle/description (which are equaly pointless from a purely technical view. Purely technical you only need channel, time & duration, see for e.g. the good old VCR. It only needed the channel, time & duration) it can be vital for the user if s/he needs to find out the culprit who programmed a timer.
I had the same question for Master-Timer years ago, because of that when Master-Timer programs a timer it also prints out which "torecord"-block (beginning on what line) was responsible for a specific timer. Then you realize that everyhing is OK, or you tune the "torecord"-block, "done" it or create a blacklist entry to get rid of the timer.
So there actually is a reason for the User to see what is recorded in the AUX-field. (And to put "meaningful"-data into the AUX-field. I'm thinking about putting some more into the AUX-field, like the meantioned block-name so that you don't have to look it up elswhere. But i haven't do that in the past because i didn't want to clutter the Summary with too much data.)
Bis denn
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
Christian Wieninger wrote:
Atleast my info about the search timer, that triggered the timer/recording will not be visible anymore. What about an additional simple submenu in the summary menu of timers/recordings, e.g. called with the unused key 'blue' labeled 'Aux'.
The 'aux' field shall be of no concern to VDR, so I don't see why there should be a button wasted to display it. What's so important about that information, anyway?
It's of no use of VDR "itself" but like the title/subitle/description (which are equaly pointless from a purely technical view. Purely technical you only need channel, time & duration, see for e.g. the good old VCR. It only needed the channel, time & duration) it can be vital for the user if s/he needs to find out the culprit who programmed a timer.
I had the same question for Master-Timer years ago, because of that when Master-Timer programs a timer it also prints out which "torecord"-block (beginning on what line) was responsible for a specific timer. Then you realize that everyhing is OK, or you tune the "torecord"-block, "done" it or create a blacklist entry to get rid of the timer.
So there actually is a reason for the User to see what is recorded in the AUX-field. (And to put "meaningful"-data into the AUX-field. I'm thinking about putting some more into the AUX-field, like the meantioned block-name so that you don't have to look it up elswhere. But i haven't do that in the past because i didn't want to clutter the Summary with too much data.)
What about defining a command in the reccmds.conf file that extracts this info from the recording's info.vdr file?
Klaus
Klaus Schmidinger wrote:
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
Christian Wieninger wrote:
Atleast my info about the search timer, that triggered the timer/recording will not be visible anymore. What about an additional simple submenu in the summary menu of timers/recordings, e.g. called with the unused key 'blue' labeled 'Aux'.
The 'aux' field shall be of no concern to VDR, so I don't see why there should be a button wasted to display it. What's so important about that information, anyway?
It's of no use of VDR "itself" but like the title/subitle/description (which are equaly pointless from a purely technical view. Purely technical you only need channel, time & duration, see for e.g. the good old VCR. It only needed the channel, time & duration) it can be vital for the user if s/he needs to find out the culprit who programmed a timer.
I had the same question for Master-Timer years ago, because of that when Master-Timer programs a timer it also prints out which "torecord"-block (beginning on what line) was responsible for a specific timer. Then you realize that everyhing is OK, or you tune the "torecord"-block, "done" it or create a blacklist entry to get rid of the timer.
So there actually is a reason for the User to see what is recorded in the AUX-field. (And to put "meaningful"-data into the AUX-field. I'm thinking about putting some more into the AUX-field, like the meantioned block-name so that you don't have to look it up elswhere. But i haven't do that in the past because i didn't want to clutter the Summary with too much data.)
What about defining a command in the reccmds.conf file that extracts this info from the recording's info.vdr file?
If i'm not mistaken we are discussing the "Timer is in the future" case, where is timer existists only in the timerlist. So there is no info.vdr. :-)
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
Christian Wieninger wrote:
Atleast my info about the search timer, that triggered the timer/recording will not be visible anymore. What about an additional simple submenu in the summary menu of timers/recordings, e.g. called with the unused key 'blue' labeled 'Aux'.
The 'aux' field shall be of no concern to VDR, so I don't see why there should be a button wasted to display it. What's so important about that information, anyway?
It's of no use of VDR "itself" but like the title/subitle/description (which are equaly pointless from a purely technical view. Purely technical you only need channel, time & duration, see for e.g. the good old VCR. It only needed the channel, time & duration) it can be vital for the user if s/he needs to find out the culprit who programmed a timer.
I had the same question for Master-Timer years ago, because of that when Master-Timer programs a timer it also prints out which "torecord"-block (beginning on what line) was responsible for a specific timer. Then you realize that everyhing is OK, or you tune the "torecord"-block, "done" it or create a blacklist entry to get rid of the timer.
So there actually is a reason for the User to see what is recorded in the AUX-field. (And to put "meaningful"-data into the AUX-field. I'm thinking about putting some more into the AUX-field, like the meantioned block-name so that you don't have to look it up elswhere. But i haven't do that in the past because i didn't want to clutter the Summary with too much data.)
What about defining a command in the reccmds.conf file that extracts this info from the recording's info.vdr file?
If i'm not mistaken we are discussing the "Timer is in the future" case, where is timer existists only in the timerlist. So there is no info.vdr. :-)
Oh, I thought this was about displaying the 'aux' string in the "Recording" menu. Well, I wouldn't mind displaying it in the "Edit timer" menu, since I myself would never see it, anyway.
Klaus
Klaus Schmidinger wrote:
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
Christian Wieninger wrote:
Atleast my info about the search timer, that triggered the timer/recording will not be visible anymore. What about an additional simple submenu in the summary menu of timers/recordings, e.g. called with the unused key 'blue' labeled 'Aux'.
The 'aux' field shall be of no concern to VDR, so I don't see why there should be a button wasted to display it. What's so important about that information, anyway?
It's of no use of VDR "itself" but like the title/subitle/description (which are equaly pointless from a purely technical view. Purely technical you only need channel, time & duration, see for e.g. the good old VCR. It only needed the channel, time & duration) it can be vital for the user if s/he needs to find out the culprit who programmed a timer.
I had the same question for Master-Timer years ago, because of that when Master-Timer programs a timer it also prints out which "torecord"-block (beginning on what line) was responsible for a specific timer. Then you realize that everyhing is OK, or you tune the "torecord"-block, "done" it or create a blacklist entry to get rid of the timer.
So there actually is a reason for the User to see what is recorded in the AUX-field. (And to put "meaningful"-data into the AUX-field. I'm thinking about putting some more into the AUX-field, like the meantioned block-name so that you don't have to look it up elswhere. But i haven't do that in the past because i didn't want to clutter the Summary with too much data.)
What about defining a command in the reccmds.conf file that extracts this info from the recording's info.vdr file?
If i'm not mistaken we are discussing the "Timer is in the future" case, where is timer existists only in the timerlist. So there is no info.vdr. :-)
Oh, I thought this was about displaying the 'aux' string in the "Recording" menu. Well, I wouldn't mind displaying it in the "Edit timer" menu, since I myself would never see it, anyway.
Christian actually meant both cases.
Whereas i was only talking about the Timer-Menu, because i think it is (more) important to be able to figure out the culprit of a timer before it records. You may want (or have to) eliminate a timer before it records for whatever reason.
Bis denn
Am Mittwoch, 22. Februar 2006 17:45 schrieb Klaus Schmidinger:
Oh, I thought this was about displaying the 'aux' string in the "Recording" menu. Well, I wouldn't mind displaying it in the "Edit timer" menu, since I myself would never see it, anyway.
where do you plan to display the info and how can one invoke it?
Will the current behaviour of the 'ok' key (displaying the summary, after the change only the original EPG) be kept? If so, one could place an addtional submenu here that displays the AUX field. If you can agree with that, I suggest to do the same for the recording summary. (Just another try ;-) )
Christian
Christian Wieninger wrote:
Am Mittwoch, 22. Februar 2006 17:45 schrieb Klaus Schmidinger:
Oh, I thought this was about displaying the 'aux' string in the "Recording" menu. Well, I wouldn't mind displaying it in the "Edit timer" menu, since I myself would never see it, anyway.
where do you plan to display the info and how can one invoke it?
I would display it in the last line of the "Edit timer" menu.
Will the current behaviour of the 'ok' key (displaying the summary, after the change only the original EPG) be kept?
No. The Ok key will always open the "Edit timer" menu. There will probably be a way of displaying the actual event a timer it currently assigned to. Presumably I'll take the "Edit" functionality off the Red button (that's available with Ok, anyway) and shift that which the Blue button currently does to the Red one (which would also prevent users from inadvertently disabling a timer when invoking the "Timers" menu with the Blue key). The Blue key will then display the event info.
If so, one could place an addtional submenu here that displays the AUX field.
The 'aux' field will be displayed in a single line, like all the other timer parameters. After all, it's just supposed to be a way of marking timers for external applications, so there shouldn't be tons of text in there (of course there can be, but only the first part of it will be visible).
If you can agree with that, I suggest to do the same for the recording summary. (Just another try ;-) )
Well, if it makes you happy, I can display this single line at the end of the "Recording" menu, too ;-) Since I myself won't ever be bothered with this, I don't care about it.
Klaus
Am Mittwoch, 22. Februar 2006 21:55 schrieb Klaus Schmidinger:
The 'aux' field will be displayed in a single line, like all the other timer parameters. After all, it's just supposed to be a way of marking timers for external applications, so there shouldn't be tons of text in there (of course there can be, but only the first part of it will be visible).
ah, good to know. So there will also be no translation from pipe to NL anymore? I currently rely on this, but that's no problem.
Well, if it makes you happy, I can display this single line at the end of the "Recording" menu, too ;-)
It does! ;-)
Christian
Christian Wieninger wrote:
Am Mittwoch, 22. Februar 2006 21:55 schrieb Klaus Schmidinger:
The 'aux' field will be displayed in a single line, like all the other timer parameters. After all, it's just supposed to be a way of marking timers for external applications, so there shouldn't be tons of text in there (of course there can be, but only the first part of it will be visible).
ah, good to know. So there will also be no translation from pipe to NL anymore? I currently rely on this, but that's no problem.
The string will be completely untouched by VDR. It's only supposed to serve as a marker for external applications.
Klaus
Hi,
The 'aux' field shall be of no concern to VDR, so I don't see why there should be a button wasted to display it. What's so important about that information, anyway?
It's not very important. The info about the search timer responsible for the recording was simply a user request. The same with the channel info. Atleast for the latter one could contact the skin authors. Besides that, I don't think the button is wasted, since its not used til now and there would be still one left (yellow).
Christian
Christian Wieninger wrote:
Hi,
The 'aux' field shall be of no concern to VDR, so I don't see why there should be a button wasted to display it. What's so important about that information, anyway?
It's not very important. The info about the search timer responsible for the recording was simply a user request. The same with the channel info. Atleast for the latter one could contact the skin authors.
You could also define a command in the reccmds.conf file that extracts this information from the recording's info.vdr file.
Besides that, I don't think the button is wasted, since its not used til now and there would be still one left (yellow).
The color buttons are a very limited resource, and I tend to preserve them for VDR's own requirements ,-)
Klaus
Hi,
Am Dienstag, 21. Februar 2006 22:14 schrieb Klaus Schmidinger:
afraid there's no time for pre-patches. However, since this thread is supposed to define exactly how things are going to be changed, you should be able to prepare your particular tool accordingly.
sorry, not completly ;-) What about the SVDRP commands NEWT and MODT? Will there be an API change or will the summary argument automatically be stored in the new AUX field with the next version?
What about cTimer::Summary(), cRecordingInfo::Description()? Will they be kept, and if so, will they exactly return the original EPG content? Will there be new functions like cTimer::Aux() and cRecordingInfo::Aux()?
Christian
Christian Wieninger wrote:
Hi,
Am Dienstag, 21. Februar 2006 22:14 schrieb Klaus Schmidinger:
afraid there's no time for pre-patches. However, since this thread is supposed to define exactly how things are going to be changed, you should be able to prepare your particular tool accordingly.
sorry, not completly ;-) What about the SVDRP commands NEWT and MODT? Will there be an API change or will the summary argument automatically be stored in the new AUX field with the next version?
The last field of the timer record will simply be handled as 'aux'. So there's no API change at the SVDRP level.
What about cTimer::Summary(), cRecordingInfo::Description()? Will they be kept, and if so, will they exactly return the original EPG content?
cTimer::Summary() will be renamed to cTimer::Aux(). cRecordingInfo::Description() will not be changed.
Will there be new functions like cTimer::Aux() and cRecordingInfo::Aux()?
Yes.
Klaus
Hi Klaus!
Klaus Schmidinger schrieb:
Christian Wieninger wrote:
or the search timer that was responsible for the timer. I think, VDRAdmin works the same way. After the recording is done this info was available til now in the recordings description. If I understood you right, this info should now be moved to the 'aux' field. Do you plan any way, to display the 'aux' value for timers and recordings in VDR's OSD?
The recorded channel is already stored in the 'C' record of the info.vdr file. If necessary, that information can be displayed in the cSkin::SetRecording() function. The actual "aux" value of a timer has no conceivable meaning to VDR, so there's no point in displaying it, I'd say.
But isn't that just private information? I don't see any way to get that information except reading the info-File directly. Could you please add a function to derive this information as I think this could be a nice feature in a skin? Though there would be a little problem, if the channel on whicht the recording was made, has changed one of the significant pids or isn't available (delted) anymore. But that wouldn't be such a big problem IMHO.
Bye, Andreas Brugger
Andreas Brugger wrote:
Hi Klaus!
Klaus Schmidinger schrieb:
Christian Wieninger wrote:
or the search timer that was responsible for the timer. I think, VDRAdmin works the same way. After the recording is done this info was available til now in the recordings description. If I understood you right, this info should now be moved to the 'aux' field. Do you plan any way, to display the 'aux' value for timers and recordings in VDR's OSD?
The recorded channel is already stored in the 'C' record of the info.vdr file. If necessary, that information can be displayed in the cSkin::SetRecording() function. The actual "aux" value of a timer has no conceivable meaning to VDR, so there's no point in displaying it, I'd say.
But isn't that just private information? I don't see any way to get that information except reading the info-File directly. Could you please add a function to derive this information as I think this could be a nice feature in a skin?
There will be a function to retrieve the 'aux' string from cRecordingInfo. However, I don't see what a skin (that doesn't know anything about what the actual content of that string means) could reasonably do with it. Sure, it could display it, ending up in something like
Aux: 123blafaslhisomeinf456this789ismystring
Meaning: the string could be *anything* (even non-printable characters).
Though there would be a little problem, if the channel on whicht the recording was made, has changed one of the significant pids or isn't available (delted) anymore. But that wouldn't be such a big problem IMHO.
Well, that's always a problem.
Klaus
Klaus Schmidinger schrieb:
Andreas Brugger wrote:
Hi Klaus!
Klaus Schmidinger schrieb:
Christian Wieninger wrote:
or the search timer that was responsible for the timer. I think, VDRAdmin works the same way. After the recording is done this info was available til now in the recordings description. If I understood you right, this info should now be moved to the 'aux' field. Do you plan any way, to display the 'aux' value for timers and recordings in VDR's OSD?
The recorded channel is already stored in the 'C' record of the info.vdr file. If necessary, that information can be displayed in the cSkin::SetRecording() function. The actual "aux" value of a timer has no conceivable meaning to VDR, so there's no point in displaying it, I'd say.
But isn't that just private information? I don't see any way to get that information except reading the info-File directly. Could you please add a function to derive this information as I think this could be a nice feature in a skin?
There will be a function to retrieve the 'aux' string from cRecordingInfo. However, I don't see what a skin (that doesn't know anything about what the actual content of that string means) could reasonably do with it. Sure, it could display it, ending up in something like
Aux: 123blafaslhisomeinf456this789ismystring
Meaning: the string could be *anything* (even non-printable characters).
Sorry, my question wasn't written very well. I meant the channelID. Is there (or will there be) a way to retreive this ID from the info.vdr via the API? I think the aux-field would always have to be acessable via the API to use it plugins and not just scripts. But I don't know either if viewing this info in the skin makes any sense ...
Bye, Andreas Brugger
Andreas Brugger wrote:
Klaus Schmidinger schrieb:
Andreas Brugger wrote:
Hi Klaus!
Klaus Schmidinger schrieb:
Christian Wieninger wrote:
or the search timer that was responsible for the timer. I think, VDRAdmin works the same way. After the recording is done this info was available til now in the recordings description. If I understood you right, this info should now be moved to the 'aux' field. Do you plan any way, to display the 'aux' value for timers and recordings in VDR's OSD?
The recorded channel is already stored in the 'C' record of the info.vdr file. If necessary, that information can be displayed in the cSkin::SetRecording() function. The actual "aux" value of a timer has no conceivable meaning to VDR, so there's no point in displaying it, I'd say.
But isn't that just private information? I don't see any way to get that information except reading the info-File directly. Could you please add a function to derive this information as I think this could be a nice feature in a skin?
There will be a function to retrieve the 'aux' string from cRecordingInfo. However, I don't see what a skin (that doesn't know anything about what the actual content of that string means) could reasonably do with it. Sure, it could display it, ending up in something like
Aux: 123blafaslhisomeinf456this789ismystring
Meaning: the string could be *anything* (even non-printable characters).
Sorry, my question wasn't written very well. I meant the channelID. Is there (or will there be) a way to retreive this ID from the info.vdr via the API?
Oh, sorry. There is currently no such function, but that can be provided.
Klaus
Dirk wrote:
Klaus Schmidinger wrote:
- The upper 16 bit of the timer's 'flag' field are no longer given any special treatment, and also shouldn't be used. Only the flags defined in vdr.5 shall be used.
I am using a script I wrote to add and manage my timers automatically. The script is using these upper 16 bits to identify which timers have been added by the script and which have been added or changed manually. This is done by setting an id (magic number) in these upper 16 bits. Later, only timers which have this id are touched (modified) by the script.
The thing I like is the fact that (from vdr.5) "When a user modifies an active timer, the upper 16 bits of this unsigned 32 bit parameter will be explicitly set to 0." Because of this, my script doesn't overwrite manual changes of the timers.
How can this be achieved in your new concept? (Any positive answer is ok for me - it is no problem to change my script.)
First: I was the one suggesting the ID-thing a few years ago for Master-Timer and i used the ID-field for Master-Timer until the current version from a month ago. But the problem is that the content of this field doesn't go into the info.vdr (or summary.vdr before) so i always (had to) additionally marked the timer in the summary-field to be able to look up the data Master-Timer stored for a timer, from the info.vdr, when the timer is long gone.
I realized some month ago that you have a fundamental problem with changing EPG-data when you mark a timer as "off limits", so i dropped that whole ID-thing altogether in favour of the ability to propagate changes in EPG-Data and timer definition to the timer (e.g. changes in time or title/subtitle/description).
As Master-Timer only changes a timer when there was a change in EPG-Data (or torecord) in normal circumstances Master-Timer doesn't touch already programmed timers.
You could store the content of a timer as a whole to see if it is modified. If you can't find your timer with a list of complete lines then it was modified or deleted.
This is basically what Master-Timer does when it wants to propagate a change in EPG-Data or timer definition, it looks up the timer via it's ID (in the Summary-field) and does a "if ($VDR_Timer ne $my_timer)" and "MODT"s the timer if it doesn't match.
Here's an updated version of the draft for eliminating the 'summary' field of timers:
- The 'summary' field in the timer definition becomes a pure string parameter, into which (external) applications can write whatever they like. VDR will read and write it, but otherwise won't do anything with it. The name of this field will be changed to 'aux'.
- The description of a recording is taken exclusively from its related EPG data. If an application wants to use a different description it will have to set it with SVDRP/PUTE and use table ID 0x00, so that it won't be overwritten (as a side effect, however, this will also disable VPS for such an event). An added bonus of this method is be that not only the 'description' can be set, but also 'title' and 'short text'.
- The upper 16 bit of the timer's 'flag' field are no longer given any special treatment, and also shouldn't be used. Only the flags defined in vdr.5 shall be used.
- The new flag tfModified = 0x8000 will be _set_ whenever the user modifies a timer via the "Edit timer" menu after the timer has been created.
- The cEvent::eventID is changed to u_int32_t so that fake event ids won't collide with real ones (by using values greater than 0xFFFF).
- The 'E' record of the recording's EPG data will also be written into 'info.vdr'.
- A new record in 'info.vdr' will hold the 'aux' string of the timer that created this recording. The tag character for this record will be '@'.
If we can agree on these changes before next weekend, I will incorporate them into the upcoming version 1.4.
Klaus
Klaus Schmidinger wrote:
- A new record in 'info.vdr' will hold the 'aux' string of the timer that created this recording. The tag character for this record will be '@'.
So additional to C, T, S, D, X(, E) there will (or may) be a @-line?
Bis denn
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
- A new record in 'info.vdr' will hold the 'aux' string of the timer that created this recording. The tag character for this record will be '@'.
So additional to C, T, S, D, X(, E) there will (or may) be a @-line?
Exactly. Didn't want to waste an actual letter because those might be put to better use for actual VDR parameters later.
Klaus
Klaus Schmidinger wrote:
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
- A new record in 'info.vdr' will hold the 'aux' string of the timer that created this recording. The tag character for this record will be '@'.
So additional to C, T, S, D, X(, E) there will (or may) be a @-line?
Exactly. Didn't want to waste an actual letter because those might be put to better use for actual VDR parameters later.
There pretty much can't be many things for YEARS to come. Unless you count the data(fields) which are available in external sources. But for you already said that you won't "waste" letters for such things like 'category', 'actors', 'director', 'country of origin', 'original title', ....
So taking the 6(7 with V) used letters there are 19 "spare" letters including the "A"UX-letter.
But when you want to have 19 (+ a truckload of more non-letter characters) or IOW 300% chars in reserve who am i to call that a strange decision.
Bis denn
Klaus Schmidinger wrote:
Here's an updated version of the draft for eliminating the 'summary' field of timers: ...
- The new flag tfModified = 0x8000 will be _set_ whenever the user modifies a timer via the "Edit timer" menu after the timer has been created.
After more consideration I don't like this any more. This flag would typically be set on a normal (i.e. plain vanilla) VDR (where users manage their timers through the "Edit timer" menu), making the flag numbers unnecessary large. Since I originally wanted to keep all auxiliary information confined to the 'aux' field (and the fact that a timer has been modified can only be of interest to external apps that use the 'aux' field), and just clearing the 'aux' field in such a case was objected to by Matthias, I tend to define that if the first character of the 'aux' field is a '?' (question mark), that character will be set to '!' (exclamation mark) if the timer was modified. As a mnemonic: "?..." asks whether the timer was modified, and "!..." means "Yes! The timer was modified".
Of course we can use a different pair of characters if somebody comes up with a suggestion.
Klaus
Klaus Schmidinger wrote:
Klaus Schmidinger wrote:
Here's an updated version of the draft for eliminating the 'summary' field of timers: ...
- The new flag tfModified = 0x8000 will be _set_ whenever the user modifies a timer via the "Edit timer" menu after the timer has been created.
After more consideration I don't like this any more. This flag would typically be set on a normal (i.e. plain vanilla) VDR (where users manage their timers through the "Edit timer" menu), making the flag numbers unnecessary large. Since I originally wanted to keep all auxiliary information confined to the 'aux' field (and the fact that a timer has been modified can only be of interest to external apps that use the 'aux' field), and just clearing the 'aux' field in such a case was objected to by Matthias, I tend to define that if the first character of the 'aux' field is a '?' (question mark), that character will be set to '!' (exclamation mark) if the timer was modified. As a mnemonic: "?..." asks whether the timer was modified, and "!..." means "Yes! The timer was modified".
Of course we can use a different pair of characters if somebody comes up with a suggestion.
I'm for dropping this topic altogether as there is NO way that anyone, except the original program, can mark or tell if a timer is modified or not with a resonable enough reliability.
Every schema we draw up won't work for more than a subset of the cases, so every programm still has to draw up a solution for the rest of the cases. Which makes it a pointless affort as you practically always end up having to remember what you programmed and comparing that to what is programmed now, to be sure there was a modification or not.
I say that is nothing Klaus should be concerend about as there is not much VDR can do, as said all schema can't catch all modifications.
VDR can catch: - Modification via OSD
VDR can not catch: - Modification via SVDR (telnet or modt.pl) - Modification via VDRAdmin, XXV ... (technically this is also SVDR) - MOdification of timers.conf when VDR is not running - Anything i forgot. :-)
Matthias Schniedermeyer wrote:
Klaus Schmidinger wrote:
Klaus Schmidinger wrote:
Here's an updated version of the draft for eliminating the 'summary' field of timers: ...
- The new flag tfModified = 0x8000 will be _set_ whenever the
user modifies a timer via the "Edit timer" menu after the timer has been created.
After more consideration I don't like this any more. This flag would typically be set on a normal (i.e. plain vanilla) VDR (where users manage their timers through the "Edit timer" menu), making the flag numbers unnecessary large. Since I originally wanted to keep all auxiliary information confined to the 'aux' field (and the fact that a timer has been modified can only be of interest to external apps that use the 'aux' field), and just clearing the 'aux' field in such a case was objected to by Matthias, I tend to define that if the first character of the 'aux' field is a '?' (question mark), that character will be set to '!' (exclamation mark) if the timer was modified. As a mnemonic: "?..." asks whether the timer was modified, and "!..." means "Yes! The timer was modified".
Of course we can use a different pair of characters if somebody comes up with a suggestion.
I'm for dropping this topic altogether as there is NO way that anyone, except the original program, can mark or tell if a timer is modified or not with a resonable enough reliability.
Every schema we draw up won't work for more than a subset of the cases, so every programm still has to draw up a solution for the rest of the cases. Which makes it a pointless affort as you practically always end up having to remember what you programmed and comparing that to what is programmed now, to be sure there was a modification or not.
I say that is nothing Klaus should be concerend about as there is not much VDR can do, as said all schema can't catch all modifications.
VDR can catch:
- Modification via OSD
VDR can not catch:
- Modification via SVDR (telnet or modt.pl)
- Modification via VDRAdmin, XXV ... (technically this is also SVDR)
- MOdification of timers.conf when VDR is not running
- Anything i forgot. :-)
Well, if we can drop that altogether, I'm all for that!
Klaus
Klaus Schmidinger wrote:
After more consideration I don't like this any more. This flag would typically be set on a normal (i.e. plain vanilla) VDR (where users manage their timers through the "Edit timer" menu), making the flag numbers unnecessary large.
You could just reverse the bit meaning, and clear that bit on edit. Only external programs that want to check for modifications would set that bit then.
Just my 2c - dont need it either.
Cheers,
Udo
Udo Richter wrote:
Klaus Schmidinger wrote:
After more consideration I don't like this any more. This flag would typically be set on a normal (i.e. plain vanilla) VDR (where users manage their timers through the "Edit timer" menu), making the flag numbers unnecessary large.
You could just reverse the bit meaning, and clear that bit on edit. Only external programs that want to check for modifications would set that bit then.
I'm having a deja vu.
tfUnmodified = 0xffff0000
:-)
Bis denn
Matthias Schniedermeyer wrote:
Udo Richter wrote:
Klaus Schmidinger wrote:
After more consideration I don't like this any more. This flag would typically be set on a normal (i.e. plain vanilla) VDR (where users manage their timers through the "Edit timer" menu), making the flag numbers unnecessary large.
You could just reverse the bit meaning, and clear that bit on edit. Only external programs that want to check for modifications would set that bit then.
I'm having a deja vu.
tfUnmodified = 0xffff0000
:-)
Well, as you yourself have already pointed out, an external application needs to keep track of its own timers, so there wont't be any such flag handling any more.
Klaus
Klaus Schmidinger wrote: ...
The 'summary' field in the timer definition becomes a pure string parameter, into which (external) applications can write whatever they like. VDR will read and write it, but otherwise won't do anything with it. The name of this field would be changed to something like 'aux' or so.
The description of a recording is taken exclusively from its related EPG data. If an application wants to use a different description it would have to set it with SVDRP/PUTE and use table ID 0x00, so that it won't be overwritten (as a side effect, however, this would also disable VPS for such an event). An added bonus of this method would be that not only the 'description' can be set, but also 'title' and 'short text'.
I like the fact that all my recordings have a summary - even those that are recorded from channels which do not have any EPG info.
This is because epg2timers takes the summary from the web EPG and enters it into the timer entry. When the actual recording takes place, vdr moves the summary into the info.vdr file.
This is nice as it is. I would consider it a step backwards if you break it.
Carsten.
Carsten Koch wrote:
Klaus Schmidinger wrote: ...
The 'summary' field in the timer definition becomes a pure string parameter, into which (external) applications can write whatever they like. VDR will read and write it, but otherwise won't do anything with it. The name of this field would be changed to something like 'aux' or so.
The description of a recording is taken exclusively from its related EPG data. If an application wants to use a different description it would have to set it with SVDRP/PUTE and use table ID 0x00, so that it won't be overwritten (as a side effect, however, this would also disable VPS for such an event). An added bonus of this method would be that not only the 'description' can be set, but also 'title' and 'short text'.
I like the fact that all my recordings have a summary - even those that are recorded from channels which do not have any EPG info.
This is because epg2timers takes the summary from the web EPG and enters it into the timer entry. When the actual recording takes place, vdr moves the summary into the info.vdr file.
This is nice as it is. I would consider it a step backwards if you break it.
Carsten.
You could just as well insert the summary into a fake EPG event for that channel (even with separate "title", "short text" and "description") and VDR would pick it up when the recording starts.
Note that I'd really like to get rid of the 'summary' mechanism, so unless you can convince me that the "EPG insertion" method doesn't work for you, I still plan to make this setp forward ;-)
Klaus
Klaus Schmidinger wrote: ...
You could just as well insert the summary into a fake EPG event for that channel (even with separate "title", "short text" and "description") and VDR would pick it up when the recording starts.
Note that I'd really like to get rid of the 'summary' mechanism, so unless you can convince me that the "EPG insertion" method doesn't work for you, I still plan to make this setp forward ;-)
I do not know how to insert the summary into a fake EPG event. Note that there are two ways to run epg2timers: Some people (myself included) run it between executions of VDR (so epg2timers modifies the timers.conf file directly while VDR is not running), others run it in parallel (maybe even on a different machine) and use SVDRP to send the new timer entries to a running VDR.
Carsten.
Carsten Koch wrote:
Klaus Schmidinger wrote: ...
You could just as well insert the summary into a fake EPG event for that channel (even with separate "title", "short text" and "description") and VDR would pick it up when the recording starts.
Note that I'd really like to get rid of the 'summary' mechanism, so unless you can convince me that the "EPG insertion" method doesn't work for you, I still plan to make this setp forward ;-)
I do not know how to insert the summary into a fake EPG event.
That can be done through the PUTE command. It's really a simple process.
Note that there are two ways to run epg2timers: Some people (myself included) run it between executions of VDR (so epg2timers modifies the timers.conf file directly while VDR is not running),
Well, then you can just as well also modify the epg.data file.
others run it in parallel (maybe even on a different machine) and use SVDRP to send the new timer entries to a running VDR.
In that case it's as simple as doing a PUTE.
Klaus
vdr-bounces@linuxtv.org wrote:
Klaus Schmidinger wrote: ...
The 'summary' field in the timer definition becomes a pure string parameter, into which (external) applications can write whatever they like. VDR will read and write it, but otherwise won't do anything with it. The name of this field would be changed to something like 'aux' or so.
The description of a recording is taken exclusively from its related EPG data. If an application wants to use a different description it would have to set it with SVDRP/PUTE and use table ID 0x00, so that it won't be overwritten (as a side effect, however, this would also disable VPS for such an event). An added bonus of this method would be that not only the 'description' can be set, but also 'title' and 'short text'.
I like the fact that all my recordings have a summary - even those that are recorded from channels which do not have any EPG info.
Me too, i program all my timers via skript from a website and i use the summaries to create the menues (and text) for the DVD-Menues. I also add episodenumbers to keep everything in order. So this change might have a big impact because i let the timers be programmed and change via vdradmin the summaries and titles, so i8'm finished after cutting. I don't want to change this. So if this change is what i think, than my automatic programming of timers will not work correctly and my vdrconvert scripts will create ugly dvds... :(
This is because epg2timers takes the summary from the web EPG and enters it into the timer entry. When the actual recording takes place, vdr moves the summary into the info.vdr file. This is nice as it is. I would consider it a step backwards if you break it.
Me too and i will stay with 1.3.42 for a longer time
Carsten.
/hgm.bg
... wrote:
vdr-bounces@linuxtv.org wrote:
Klaus Schmidinger wrote: ...
- The 'summary' field in the timer definition becomes a pure
string parameter, into which (external) applications can write whatever they like. VDR will read and write it, but otherwise won't do anything with it. The name of this field would be changed to something like 'aux' or so.
- The description of a recording is taken exclusively from its
related EPG data. If an application wants to use a different description it would have to set it with SVDRP/PUTE and use table ID 0x00, so that it won't be overwritten (as a side effect, however, this would also disable VPS for such an event). An added bonus of this method would be that not only the 'description' can be set, but also 'title' and 'short text'.
I like the fact that all my recordings have a summary - even those that are recorded from channels which do not have any EPG info.
Me too, i program all my timers via skript from a website and i use the summaries to create the menues (and text) for the DVD-Menues. I also add episodenumbers to keep everything in order. So this change might have a big impact because i let the timers be programmed and change via vdradmin the summaries and titles, so i8'm finished after cutting. I don't want to change this. So if this change is what i think, than my automatic programming of timers will not work correctly and my vdrconvert scripts will create ugly dvds... :(
This is because epg2timers takes the summary from the web EPG and enters it into the timer entry. When the actual recording takes place, vdr moves the summary into the info.vdr file. This is nice as it is. I would consider it a step backwards if you break it.
Me too and i will stay with 1.3.42 for a longer time
Carsten.
/hgm.bg
Well, nobody keeps you from storing anything you like in the 'aux' field of a timer. You'll find that string again in the resulting info.vdr file - it will just have a different tag character. The only change for you will be that VDR doesn't treat this data as a "description" any more. Regarding your DVD processing script I would assume that the only change you'd have to make is replacing a 'D' with an '@' somewhere.
Klaus
vdr-bounces@linuxtv.org wrote:
Me too, i program all my timers via skript from a website and i use the summaries to create the menues (and text) for the DVD-Menues. I also add episodenumbers to keep everything in order. So this change might have a big impact because i let the timers be programmed and change via vdradmin the summaries and titles, so i8'm finished after cutting. I don't want to change this. So if this change is what i think, than my automatic programming of timers will not work correctly and my vdrconvert scripts will create ugly dvds... :(
Well, nobody keeps you from storing anything you like in the 'aux' field of a timer. You'll find that string again in the resulting info.vdr file - it will just have a different tag character. The only change for you will be that VDR doesn't treat this data as a "description" any more. Regarding your DVD processing script I would assume that the only change you'd have to make is replacing a 'D' with an '@' somewhere.
Okay, that with the tag is no problem, but editing the summary before the recording e.g. with vdradmin and then don't find this "description" in vdr after the recording , seems strange to me (i see the advantage to have the epg-description of the recording, but what happens if you record two movies in one recording or overlap a quarter hour to be sure to have the end recorded - than you only have the last EPG-description?), why not use one of the remaining color-buttons if you open the info of recording (afaik there only red and green in use) ?
Klaus
Thanks anyway for your work Klaus !!
/hgm.bg
... wrote:
vdr-bounces@linuxtv.org wrote:
Me too, i program all my timers via skript from a website and i use the summaries to create the menues (and text) for the DVD-Menues. I also add episodenumbers to keep everything in order. So this change might have a big impact because i let the timers be programmed and change via vdradmin the summaries and titles, so i8'm finished after cutting. I don't want to change this. So if this change is what i think, than my automatic programming of timers will not work correctly and my vdrconvert scripts will create ugly dvds... :(
Well, nobody keeps you from storing anything you like in the 'aux' field of a timer. You'll find that string again in the resulting info.vdr file - it will just have a different tag character. The only change for you will be that VDR doesn't treat this data as a "description" any more. Regarding your DVD processing script I would assume that the only change you'd have to make is replacing a 'D' with an '@' somewhere.
Okay, that with the tag is no problem, but editing the summary before the recording e.g. with vdradmin and then don't find this "description" in vdr after the recording , seems strange to me (i see the advantage to have the epg-description of the recording, but what happens if you record two movies in one recording or overlap a quarter hour to be sure to have the end recorded - than you only have the last EPG-description?), why not use one of the remaining color-buttons if you open the info of recording (afaik there only red and green in use) ?
VDRAdmin can (still) change it as VDRAdmin changes via SVDR and only the (nowhere seen) NAME of the field is changed.
The field will still be the last field of a timer-line, so NEWT/MODT will work the same as before.
Regarding your last worry. I said to Klaus (before this discussion in a private mail) that he maybe should drop the "one timer, one EPG-Event"-paradigma for the info.vdr and place all EPG-Events that are (say) at least 90% overlapped with the timer. OK. That way it would be easy to catch news or any other "few minutes" things, when you use large enough margins, but i guess that would still be better than catching the wrong EPG-Event and be scewed. :-)
Bis denn
Matthias Schniedermeyer wrote:
... wrote:
vdr-bounces@linuxtv.org wrote:
Me too, i program all my timers via skript from a website and i use the summaries to create the menues (and text) for the DVD-Menues. I also add episodenumbers to keep everything in order. So this change might have a big impact because i let the timers be programmed and change via vdradmin the summaries and titles, so i8'm finished after cutting. I don't want to change this. So if this change is what i think, than my automatic programming of timers will not work correctly and my vdrconvert scripts will create ugly dvds... :(
Well, nobody keeps you from storing anything you like in the 'aux' field of a timer. You'll find that string again in the resulting info.vdr file - it will just have a different tag character. The only change for you will be that VDR doesn't treat this data as a "description" any more. Regarding your DVD processing script I would assume that the only change you'd have to make is replacing a 'D' with an '@' somewhere.
Okay, that with the tag is no problem, but editing the summary before the recording e.g. with vdradmin and then don't find this "description" in vdr after the recording , seems strange to me (i see the advantage to have the epg-description of the recording, but what happens if you record two movies in one recording or overlap a quarter hour to be sure to have the end recorded - than you only have the last EPG-description?), why not use one of the remaining color-buttons if you open the info of recording (afaik there only red and green in use) ?
VDRAdmin can (still) change it as VDRAdmin changes via SVDR and only the (nowhere seen) NAME of the field is changed.
The field will still be the last field of a timer-line, so NEWT/MODT will work the same as before.
Regarding your last worry. I said to Klaus (before this discussion in a private mail) that he maybe should drop the "one timer, one EPG-Event"-paradigma for the info.vdr and place all EPG-Events that are (say) at least 90% overlapped with the timer. OK. That way it would be easy to catch news or any other "few minutes" things, when you use large enough margins, but i guess that would still be better than catching the wrong EPG-Event and be scewed. :-)
VDR goes to great lengths to determine which EPG event to assign to a recording. It takes the one the has the most overlap with the timer, which appears to work just fine.
Klaus
... wrote:
vdr-bounces@linuxtv.org wrote:
Me too, i program all my timers via skript from a website and i use the summaries to create the menues (and text) for the DVD-Menues. I also add episodenumbers to keep everything in order. So this change might have a big impact because i let the timers be programmed and change via vdradmin the summaries and titles, so i8'm finished after cutting. I don't want to change this. So if this change is what i think, than my automatic programming of timers will not work correctly and my vdrconvert scripts will create ugly dvds... :(
Well, nobody keeps you from storing anything you like in the 'aux' field of a timer. You'll find that string again in the resulting info.vdr file - it will just have a different tag character. The only change for you will be that VDR doesn't treat this data as a "description" any more. Regarding your DVD processing script I would assume that the only change you'd have to make is replacing a 'D' with an '@' somewhere.
Okay, that with the tag is no problem, but editing the summary before the recording e.g. with vdradmin and then don't find this "description" in vdr after the recording , seems strange to me (i see the advantage to have the epg-description of the recording, but what happens if you record two movies in one recording
You can always program two overlapping timers, one for each movie. I think this is the reasonable way to do it.
or overlap a quarter hour to be sure to have the end recorded - than you only have the last EPG-description?),
VDR automatically selects the EPG entry that is covered the most by the timer. If you record a 90 minute movie and give it an extra half hour at the beginning and end, for instance, you still will have the _movie's_ EPG info with the recording.
why not use one of the remaining color-buttons if you open the info of recording (afaik there only red and green in use) ?
The "summary" field of the timers was implemented at a time when there was no EPG handling in VDR, yet. Ever since EPG is handled by VDR, the summary field is pretty much obsolete. I want to straighten things out in that area and have _one_ source of information for recordings, and that's, of course, the EPG. You can always insert external EPG data if you want, and you can still use the "aux" field for any "behind the scenes" stuff you want to handle.
Klaus
-
... -
Andreas Brachold -
Andreas Brugger -
Carsten Koch -
Christian Wieninger -
Darren Salt -
Dirk -
Klaus Schmidinger -
Matthias Schniedermeyer -
Udo Richter