[vdr] Feature request: changed/new SVDRP return codes

[Jan Ekholm <chakie@infa.abo.fi>]

Hi,

While looking a bit at parsing the SVDRP data that VDR returns I think a
small change or two to the protocol could make things a lot easier for
those using the protocol.

Currently most commands that get lists of stuff from VDR are using the
return code 250, which means "Requested VDR action okay, completed". It
can however be a bit hard to parse the data from VDR as this 250 is used
for so many things. Imagine the following:

1. client sends a LSTC
2. reads lines from VDR and parses the channels
3. client sends a LSTR
4. reads lines from VDR and parses the recordings

However, when can the client know for sure that all data that the LSTC
generates has been read and it is safe to send to LSTR? Timeouts are a bit
of an ugly hack. Most likely VDR has sent all data when the client hasn't
got anything for, say, 10 seconds, but one can't be really sure. It is
quite easy to mix up the lines returned by the various commands that use
250 and do a mis-parse.

I see two solutions to this thing:

1. have each command use an unique return code. This means that the return
code can directly be used to signal successful retrieval of data for a
specific command. The codes can be, say, from 250 to 300, so a client that
uses 250 to check for success can just define a successful return code to
be [250..300].

2. have specific "end of data" lines sent after each command that can
produce more than one line of output. This means that the client could
keep state of what kind of data it is now reading, and once it receives an
"end of list" line it knows it's safe to send other commands.

The first approach is already used for:

	214 Help message
	215 EPG data record

An EPG line is thus always identifiable as what it is.

The second approach is also used by the EPG listing, as a LSTE causes VDR
to send a 354 when VDR starts sending data and a "215 End of EPG data"
when all data is received. A client thus knows exactly when data is
started, can identify the lines and knows when it ends.

The simplest change would be to just add a new return code like:

 	230 End of xxxx

where xxxx is the list that is ended, such as LSTC. Commands that only
cause one line of return data would not need a terminating 230 as the
client knows to expect only one line of data.

Comments? What do you others do who use SVDRP? I know this is probably not
a too minor change and it could break stuff for clients that use SVDRP?

Actually, I started digging into VDRAdmin and see wether I could make it
work with the broken channel data our cable provider sends, but I just
couldn't grok the Perl. :) We do however need the excellent auto-timers
that VDRAdmin has provided so the easy solution is to write something
that does the auto-timing myself.

Hrmp, I hope can get some sense out of my ramblings.

-- 
   Kids! Bringing about Armageddon can be dangerous. Do not attempt it in
   your home.
                             -- Terry Pratchett & Neil Gaiman, Good Omens


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.