Hi,
I have my own reasons for this proposal, but it may be worth discussion in light of the previous thread.
There seems to be a general need to merge/modify epg data both as part of the epg and once a program becomes a timer.
is it not worth storing this extended/modified epg data in a new field in xml format. VDR could treat it as a single large string, and external programs/plugins their own way. If there was a common agreement on how to identify which format or even an agreed single format, many programs could benefit. Many already offer web/web service interfaces so already have some infrastucture to support this.
as long as changes to the records are atomic then merge, change, extend, comment all become supported, it may even be possible to allow multiple programs to re-use the string simulaneously if the right document structure is chosen.
I realise this proposal increases the work required by plugins and external programs, but I would hope there would be some long term benefits to tagging epg/timers with additional data.
Klaus I understand you have a reluctance to depend on external libraries, hence the big string proposal. Instant forwards compatibility without overcomplicating the core of vdr :-) Its got to be a good thing.
how about a stucture something like this? <DOC> <APP1_DATA version="1.0"> <Whatever/> </APP1_DATA> <APP2_DATA> <something_else/> </APP2_DATA> <APP3_DATA/> </DOC>
My own requirement is to have a smart merge function. I currently have a number of scripts that merge a web based program guide, vdr epg data and imdb data into xml based records so I can index my recordings. UK epg data does not include series/episode data, I prefer the web site long descriptions and I want more data from imdb. Currently its not worth me even trying to merge it in until after it has left vdr.
Simon
Simon Truss wrote:
Hi,
I have my own reasons for this proposal, but it may be worth discussion in light of the previous thread.
There seems to be a general need to merge/modify epg data both as part of the epg and once a program becomes a timer.
is it not worth storing this extended/modified epg data in a new field in xml format. VDR could treat it as a single large string, and external programs/plugins their own way. If there was a common agreement on how to identify which format or even an agreed single format, many programs could benefit. Many already offer web/web service interfaces so already have some infrastucture to support this.
as long as changes to the records are atomic then merge, change, extend, comment all become supported, it may even be possible to allow multiple programs to re-use the string simulaneously if the right document structure is chosen.
I realise this proposal increases the work required by plugins and external programs, but I would hope there would be some long term benefits to tagging epg/timers with additional data.
Klaus I understand you have a reluctance to depend on external libraries, hence the big string proposal. Instant forwards compatibility without overcomplicating the core of vdr :-) Its got to be a good thing.
how about a stucture something like this?
<DOC> <APP1_DATA version="1.0"> <Whatever/> </APP1_DATA> <APP2_DATA> <something_else/> </APP2_DATA> <APP3_DATA/> </DOC>
My own requirement is to have a smart merge function. I currently have a number of scripts that merge a web based program guide, vdr epg data and imdb data into xml based records so I can index my recordings. UK epg data does not include series/episode data, I prefer the web site long descriptions and I want more data from imdb. Currently its not worth me even trying to merge it in until after it has left vdr.
I'm afraid I don't quite understand what you mean with your APP1..., APP2... etc. stuff. VDR doesn't need a data structure like the one you have described above (besides, its XML - there is no XML in VDR ;-).
VDR reads the data that comes from the DVB SI data stream and stores those records it actually needs. These records can also be defined by external tools via the PUTE command and can be read by the LSTE command. Why would VDR need to store application specific stuff?
Klaus
Klaus Schmidinger wrote:
Simon Truss wrote:
is it not worth storing this extended/modified epg data in a new field in xml format. VDR could treat it as a single large string, and external programs/plugins their own way. If there was a common agreement on how to identify which format or even an agreed single format, many programs could benefit. Many already offer web/web service interfaces so already have some infrastucture to support this.
how about a stucture something like this?
<DOC> <APP1_DATA version="1.0"> <Whatever/> </APP1_DATA> <APP2_DATA> <something_else/> </APP2_DATA> <APP3_DATA/> </DOC>
I'm afraid I don't quite understand what you mean with your APP1..., APP2... etc. stuff. VDR doesn't need a data structure like the one you have described above (besides, its XML - there is no XML in VDR ;-).
Im proposing that you add the ability to store meta data along with the DVB data. VDR would treat it as a string (a long one potentially), external programs would have to parse it for their own purpose. The APPn.. idea is a side issue to allow multiple programs to tag a single entry at the same time. VDR cannot add a new storage field for each program that might want to store extra data, it would be impossible to maintain. The support for xml and agreement on how to use it as a shared resource would have to come from developers of support programs that wish to store additional data.
xml need not be pretty printed as multiple lines, a whole document can be treated as a simple null terminated string for the purposes of storage. This was to keep the added complexity low inside VDR, but allow for unexpected usage by support programs/plugins.
VDR reads the data that comes from the DVB SI data stream and stores those records it actually needs. These records can also be defined by external tools via the PUTE command and can be read by the LSTE command. Why would VDR need to store application specific stuff?
because it is related to the program event, but not part of the data provided by the DVB stream. examples might be:
comments as in the 'xxv and autotimers' thread, extended timer settings a list of cast and crew, link to imdb etc.
Simon
-
Klaus Schmidinger -
Simon Truss