Hi all,
I have finally got xxv to work which is a great web interface to vdr configuration.
I have been using AutoTimers and a couple of things are bothering me. My EPG data has full information about the nearest 2-4 hours and partial information (only time and title) about the coming 4-6 days. If I create an AutoTimer that finds a program shown 2 days from now the description of that program usually is #~AT[1]. When the recording is done all EPG data is available but vdr still records it with description #~AT[1].
Is this the normal behaviour or have I overlooked something in the config?
All hints are appreciated!
Regards,
Anders
Hi,
Anders Sandell wrote:
I have been using AutoTimers and a couple of things are bothering me. My EPG data has full information about the nearest 2-4 hours and partial information (only time and title) about the coming 4-6 days. If I create an AutoTimer that finds a program shown 2 days from now the description of that program usually is #~AT[1]. When the recording is done all EPG data is available but vdr still records it with description #~AT[1].
I get your point. I will provide a solution via our svn server, this or next day.
#~AT[1] is used as marker / anchor to reidentify a timer by xxv.
BTW:
I would wish myself in addition a feature on the part of the VDR, which external programs can provide on vdr timers with additional data fields. That to however only go if the timer format like e.g. the EPG format is developed and the VDR here external data permits. The vdradmin solution to stores the EventID as bitfield on TIMERID is similarly dirty.
like this idea for a new timer dataformat --- E start point T title~subtitle D description U <- this field could used by vdradmin or xxv with owner data -> e ---
Cu Andreas
Andreas Brachold wrote:
... I would wish myself in addition a feature on the part of the VDR, which external programs can provide on vdr timers with additional data fields. That to however only go if the timer format like e.g. the EPG format is developed and the VDR here external data permits. The vdradmin solution to stores the EventID as bitfield on TIMERID is similarly dirty.
like this idea for a new timer dataformat
E start point T title~subtitle D description U <- this field could used by vdradmin or xxv with owner data -> e
The timer format is a one line format and it will stay that way. If you want to store additional data, you could do so in the "summary" field.
Klaus
Hi,
Klaus Schmidinger wrote:
The timer format is a one line format and it will stay that way. If you want to store additional data, you could do so in the "summary" field.
I'm unhappy, but that not really important.
As additional comment :
XXV already make this too. But this additional data are only interesting during the lifetime of timers. And it is could feel bothering at description on recording. I think this solution current only a quick and dirty workaround.
Andreas
Andreas Brachold schrieb:
Hi,
Klaus Schmidinger wrote:
The timer format is a one line format and it will stay that way. If you want to store additional data, you could do so in the "summary" field.
I'm unhappy, but that not really important.
Me too, but i have write a comment in bugzilla to resolve this Problem. But we need in vdr a feature to make hidden the Comments from external programs. The User see all the time the Comments from xxv, i.e. the AT.
As additional comment :
XXV already make this too. But this additional data are only interesting during the lifetime of timers. And it is could feel bothering at description on recording. I think this solution current only a quick and dirty workaround.
Andreas
@Klaus
Can you make hidden the Comments in vdr?
cu Frank (xpix) Herrmann
xpix wrote:
Andreas Brachold schrieb:
Hi,
Klaus Schmidinger wrote:
The timer format is a one line format and it will stay that way. If you want to store additional data, you could do so in the "summary" field.
I'm unhappy, but that not really important.
Me too, but i have write a comment in bugzilla to resolve this Problem. But we need in vdr a feature to make hidden the Comments from external programs. The User see all the time the Comments from xxv, i.e. the AT.
As additional comment : XXV already make this too. But this additional data are only interesting during the lifetime of timers. And it is could feel bothering at description on recording. I think this solution current only a quick and dirty workaround.
Andreas
@Klaus
Can you make hidden the Comments in vdr?
cu Frank (xpix) Herrmann
The 'summary' field in timers.conf, if present, is used as the 'description' text in info.vdr when a recording is made (and overwrites whatever came from the related EPG data).
Personally I don't use that field in any way, so if we could agree on some delimiting character that separates 'description' from 'comment', as in
...:Description of what happens#some arbitrary comment
where '#' would be that new delimiter. Everything before the delimiter would go into the 'description', and everything after it would simply be stored and otherwise ignored by VDR.
If we do this I would also like to make the use of the high 16 bit of the 'status' field obsolete, since this information can and should then be stored in the 'comment'.
Klaus
Klaus Schmidinger wrote: ...
The 'summary' field in timers.conf, if present, is used as the 'description' text in info.vdr when a recording is made (and overwrites whatever came from the related EPG data).
I wonder if it would be an improvement of that strategy if VDR only took the summary from the timer entry if it is not much shorter than the summary from the related EPG data.
Personally I don't use that field in any way, so if we could agree on some delimiting character that separates 'description' from 'comment', as in
...:Description of what happens#some arbitrary comment
where '#' would be that new delimiter. Everything before the delimiter would go into the 'description', and everything after it would simply be stored and otherwise ignored by VDR.
I would not like such a change unless you choose a character that is guranteed not to occur in a tvtv.de summary. ;-)
If you do make that change, please remind me to release a new version of epg2timers that converts this character (if found in the tvtv.de summary) into something else.
Carsten.
On Tuesday 13 September 2005 19:01, Carsten Koch wrote:
I wonder if it would be an improvement of that strategy if VDR only took the summary from the timer entry if it is not much shorter than the summary from the related EPG data.
The length of the description is not always a good criterion for being up-to-date. Some providers send a standard description and replace it a few days before the event with something thats up-to-date but perhaps shorter.
On Tuesday 13 September 2005 18:10, Klaus Schmidinger wrote:
delimiting character that separates 'description' from 'comment', as in
...:Description of what happens#some arbitrary comment
where '#' would be that new delimiter. Everything before the delimiter would go into the 'description', and everything after it would simply be stored and otherwise ignored by VDR.
The delimiter could be a problem, but what about a sequence like CR#CR? Can't imagine, that this is part of a description. Another question: Would this comment be absolutely invisible in VDR (in timers and recordings summary)? If so, will there be a method like cTimer::Comment(), so that plugins could also use it? Would be great! ;-)
Christian
Hello Klaus,
Klaus Schmidinger schrieb:
The 'summary' field in timers.conf, if present, is used as the 'description' text in info.vdr when a recording is made (and overwrites whatever came from the related EPG data).
Personally I don't use that field in any way, so if we could agree on some delimiting character that separates 'description' from 'comment', as in
...:Description of what happens#some arbitrary comment
where '#' would be that new delimiter. Everything before the delimiter would go into the 'description', and everything after it would simply be stored and otherwise ignored by VDR.
If we do this I would also like to make the use of the high 16 bit of the 'status' field obsolete, since this information can and should then be stored in the 'comment'.
Yes sounds very good, make ist so! ;)
cu Frank Herrmann
Carsten Koch wrote:
Klaus Schmidinger wrote: ...
The 'summary' field in timers.conf, if present, is used as the 'description' text in info.vdr when a recording is made (and overwrites whatever came from the related EPG data).
I wonder if it would be an improvement of that strategy if VDR only took the summary from the timer entry if it is not much shorter than the summary from the related EPG data.
I don't think this would be a good idea, since there would always be cases where somebody would have preferred it the other way ;-) It's either there or not, and if it's there, it will be used.
Personally I don't use that field in any way, so if we could agree on some delimiting character that separates 'description' from 'comment', as in
...:Description of what happens#some arbitrary comment
where '#' would be that new delimiter. Everything before the delimiter would go into the 'description', and everything after it would simply be stored and otherwise ignored by VDR.
I would not like such a change unless you choose a character that is guranteed not to occur in a tvtv.de summary. ;-)
I won't be choosing that character, because I don't need that feature ;-) The VDR community will have to make a suggestion.
If you do make that change, please remind me to release a new version of epg2timers that converts this character (if found in the tvtv.de summary) into something else.
You'll see this in VDR/HISTORY, should it ever happen.
Klaus
Christian Wieninger wrote:
... On Tuesday 13 September 2005 18:10, Klaus Schmidinger wrote:
delimiting character that separates 'description' from 'comment', as in
...:Description of what happens#some arbitrary comment
where '#' would be that new delimiter. Everything before the delimiter would go into the 'description', and everything after it would simply be stored and otherwise ignored by VDR.
The delimiter could be a problem, but what about a sequence like CR#CR?
If by CR you mean 0x0A ("carriage return") then I disagree. It has to be a printable character in order to work with SVDRP.
Can't imagine, that this is part of a description. Another question: Would this comment be absolutely invisible in VDR (in timers and recordings summary)? If so, will there be a method like cTimer::Comment(), so that plugins could also use it? Would be great! ;-)
I guess this should be possible. VDR by itself would completely ignore it, though.
Klaus
On Saturday 17 September 2005 11:53, Klaus Schmidinger wrote:
If by CR you mean 0x0A ("carriage return") then I disagree. It has to be a printable character in order to work with SVDRP.
in the context of SVDRP it should translate with pipes to "|#|", as you already do it for other linefeeds.
Christian
Christian Wieninger wrote:
On Saturday 17 September 2005 11:53, Klaus Schmidinger wrote:
If by CR you mean 0x0A ("carriage return") then I disagree. It has to be a printable character in order to work with SVDRP.
in the context of SVDRP it should translate with pipes to "|#|", as you already do it for other linefeeds.
Christian
I would prefer a _single_ delimiting character.
Klaus
On Saturday 17 September 2005 12:04, Klaus Schmidinger wrote:
I would prefer a _single_ delimiting character.
me too. But '#' will probably not work unless its not restricted to be at the beginning of a line (thats already nearly a sequence ;-) ):
E 1137 1126788300 1800 0 T Friends ... (Gunther), Simon Harvey (Jester), Shashi Bhatia (Schauspielschüler #1), Steven Harad (Schauspielschüler #2)|Category: Serie|Genre: Sitcom|Year: 1996|Originalti tle: Friends|Format: 4:3| e
what I've not found at all in my tvmovie-EPG was "^" and "~".
Perhaps someone could also check its own EPG.
Christian
On Sat, Sep 17, 2005 at 02:40:20PM +0200, Christian Wieninger wrote:
On Saturday 17 September 2005 12:04, Klaus Schmidinger wrote:
I would prefer a _single_ delimiting character.
me too. But '#' will probably not work unless its not restricted to be at the beginning of a line (thats already nearly a sequence ;-) ):
...
what I've not found at all in my tvmovie-EPG was "^" and "~".
It seems like using an escape character is the only way this is not going to break in the future.