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
