Mlists wrote:
> I am currently using an older version of VDR -- 1.3.40. It's been
> stable and working but now I want to move to the latest stable version.
>
> I use xine-network to access vdr from a remote computer connected to my
> TV. I noticed xine-network hasn't changed with the new apiversion and
> such and I haven't seen much talk about it so the question is for a
> budget card setup, is that still the best way to go or is there other
> plugins that will do this for me?
Apparently there are a few ways to do a vdr-server-with-networked-player(s), but none that is really usable; each has it's own set of problems. I was trying to move to such a setup recently and tried ffnetdev, xine and streamdev, so i might just as well share some of that experience. The streamdev-plugin is probably the best choice right now, but there's still a lot of missing functionality, not to mention the complex setup&configuration. Having said that, the way i'd do it is :
(1) vdr w/ dvb-hw and streamdev-server plus remote-plugin
(2) vdr w/ streamdev-client and softdevice, sharing /video* tree w/ server above.
That gives you a almost fully functional vdr on the client(s), you can watch live tv and replay recordings exactly as on a standalone vdr. What's missing is:
o Editing timers. On the server, that is. You can actually use the client to do recordings, but that means data is needlessly moving around the network, limits the vdr-client to the current transponder and requires the client to be always on. You can edit the vdr-server timers remotely using eg the remote-plugin or some http-based solution, but that's obviously very inconvenient for ad-hoc recordings. (one way to fix this could be to add one field to timers.conf -- "VDR-ID" (AFAICT this is what Resume-ID already is), which would allow sharing that file among all vdrs and even selecting where each recording should be done.)
o Interacting w/ ongoing recordings on the server. eg. deleting a recording while the server is writing it will succeed, but the server won't notice and keep going... Things can get even more interesting when a recording is deleted and later restarted (eg when using multiple /video{0,1,2} trees -- the /video0/* dir gets renamed, but the /video1/* ones do not)
o EPG. In practice not a big problem for programs that provide "real" EPG (ie at least multiple days); very inconvenient for the ones only supplying current&next. (this assumes sharing the EPG data file in some way, but has it's problems too, eg vdr does not write the (new) EPG data if it's currently doing a recording; this becomes a problem if it's recording practically 24/7 (eg saving radio streams in bgnd when nothing more important is happening)
o Controlling the server-vdr. some things are mentioned above, but it's also a more general problem. one solution is the remote plugins, but that's not very user friendly. OTOH this functionality is not needed by most "normal" users.
o Efficient cutting. Well, the data has to move server->client->server. In practice on 100M+ it's not that bad, but for eg wireless clients this could be a problem.
o Remote server-OSD. The remote-plugin provides OSD-over-telnet, which is enough for configuring vdr. Still, things like plugins (eg femon) do not fully work.
List is above is not complete, but these are the things i could think of right now.
Bottom line: while this kind of setup works and gives each client-vdr-user the best experience (that of a standalone vdr), there are still things missing. It's almost enough for an "advanced" user (one that won't forget about the timer/recording issues and can fix things up when he does), but certainly not for normal STB-type usage.
Setting this up is a completely different story though; documentation could be much better, there are things like
- you need the remote-plugin for a remote OSD -- which is rather non-obvious (esp. together w/ the below issue)
- with some configs vdr will switch the primary device on startup, breaking remote-osd and requiring manually editing setup.conf every time to get it back (it took me a while to figure out wtf was going on...)
- you need to fix a few things up, like streamdev-client leaking fds if the streamdev-server is not available (i've got a patch if anybody needs it; streamdev plugin authors email was bouncing)
- you need to set up fs sharing (eg NFS) and figure exactly what you want to share and what not (eg channels(yes)/timers(no)/setup(no)/epg(one way))
Hopefully this will save someone some time when setting up such a system, and maybe some of the things can be improved in in the future. It's not really that much that's missing, basically a) shared timers (see VDR-ID proposal above. and, yes, i think there wouldn't be many consistency issues, new timers could be appended to the file) b) shared epg (keeping the data in a simple external-to-vdr epg-server should be enough. With each vdr also keeping a copy there wouldn't be any latency issues, the epg-server only needs to be checked for new(er) data when actually showing the epg) and c) better handling of "busy" recordings (preventing the user from messing things up might be enough, by eg using a '.recording' file in the *.rec/ dir)
artur
