Now that you have accomplished fixing the recording playback etc. What are you working on next? How hard would it be to implement OSD or a Timeline for when you Pause etc. And what would be involved in some sort of Guide implementation to sync with the VDR EPG. I know you put the OSD in there for a reason. Just didn't know what was involved in getting the sync to take place.
Thanks again for all you have done and all your efforts to make it work for everyone. It works great with VDR 1.3.30 and playback on recordings is now flawless.
I am currently working on getting the next 24 hours of EPG for the current channel displayed in the on screen box that appears over Live TV. I have most of this working now, I just need to sort the data and it's pretty much done. That's only one part of the EPG display though, a now/next page would be nice but is not a priority, and a full guide page would be nice, but I think the GUI code might need some attention first, before I could do that. At the moment I am mainly working on the caveats list on the vomp web page so that all types of TV/signal etc can actually work. After that there are the bug lists and feature request lists on the SourceForge page. And after that, who knows... I still want to stick to the clean set top box for VDR approach, so things outside that scope are very low priority for me.
I understand completely, I don't see the need for a now/next but seeing what is on right now would be nice. I never have been real fond of the built in EPG for VDR, I of course like YAEPG! :) I wouldn't think more than 24 hours would be needed due to the fact you aren't recording on the device. Even 8 hours would be plenty. Cuz really why would you need to see what is on all day, it isn't something you can do anything about! :) Or even 12 hours max if it uses less memory etc. Didn't know how things worked, like with Streamdev-Client when it syncs the EPG if it is constantly pulling from the Server or if it pulls down a certain amount. Just doing a simple well I say simple! :) but display on the channel gui like most of the skins do showing a current and next there would be all that I would see beneficial on that when you press OK or whatnot.
Well if there is anything I can help test or whatnot let me know. Since I am NTSC! Obviously I am sure a 16:9 feature would be nice for those that have it.
Thanks for the response.
I don't have a fully featured receiver card so I've never seen the VDR frontend. What is YAEPG?
I am trying to get a fairly decent EPG system working because I would like to interact with the VDR timers one day in the dim and distant future. I would like to be able to duplicate all the functionality of the web LinVDR admin system into vomp. As yet I can decide how to do EPG best for the MVP. I was pleased to find that 24 hours of a single channel including descriptions is just a few KB which is nicely manageable for the MVP. I am going to get the current on screen box working, and then go back to widescreen. Which is a PITA. I would have done it already, but the video chip just seems to make up its own rules about when to do widescreen and not. I actually moved onto this EPG system which I had been dreading for ages.. that's how bad it was ;)
YAEPG is just a GUI that accesses the VDR EPG. Obviously you wouldn't be able to use it on the MVP but something of sorts on looks would be nice, but I completely understand. And I use the VDRAdmin all the time so that sounds slick. Here is a Screenshot of YAEPG.
http://www.linuxtv.org/vdrwiki/index.php/Image:Yaepg-plugin.jpg
Would be nice to be able to setup recordings through the MVP obviously storing them on the VDR System I could see that feasibility. I don't have widescreen, my parents do and I will be ordering an MVP for them soon, which is why I put that comment in there! :) But I personally think OSD and GUIDE functionality is more important. And you don't have to have a FF card for the VDR GUI, how do you use VDR? Through TVTime or XAW or something? You can still run YAEPG etc using all that on your VDR System. If you need help let me know. But at best just getting what you have implemented already working with what is on currently would be slick in itself. Like I said at best would be to go with how most of the VDR Skins work which shows what is on now, and what is on next in that little box.
http://www.vdrskins.org/vdrskins/displayimage.php?album=41&pos=1
I will work more on getting one of my buddies that does a lot of patching etc for VDR and understands this way more than I ever could to get a MVP hehe, he is drooling over mine now. And I can get him to help us out on this. He would understand it a lot more and understands GUI etc on the stuff.
Yes, YAEPG looks good. I think that is what I will work towards when I get onto the main EPG page. I know that the MVP can do quarter screen video and have the OSD on the rest of the screen so yes, that should be very possible.
And wow, that VDR skin looks nice. It could be a long time before vomp looks that nice!
I only use VDR as a backend recorder, actually it runs on a headless big noisy server box in another room. I have always used only the MVP to watch its recordings. But just out of interest, how is it possible to use the generic tv applications and still see the VDR gui? Or am I just missing something here...
Do you run any sort of GUI on your system that runs VDR? Like Xwindows or Xorg? You use Debian! :) You are using the better of the systems hehe, ok well just my opinion but anyways! :) If running gui, just apt-get install tvtime, and ideally you should be able to see your VDR Gui. Another option that is similar to how you do MVP is setup a VDR Client system. I use my laptop and install VDR on it with Streamdev-Client and the Xine Plugin. You get full VDR GUI that way too. Check out my site, I need to update my Xine Howto but should be straight forward. My site is designed around Debian and also a lot of my stuff is for NTSC but it shouldn't be anything special for your intentions. Especially if running on a laptop or whatnot.
http://www.hoochvdr.info
I try and focus on a ENGLISH Wiki for VDR basically. Trying to keep info current as possible so that it isn't confusing. VDRPortal.de is great but there is so much stuff on there it can get confusing. But be happy to help ya through it. But that is the Enigma Skin for VDR. And in my opinion one of the best skins! Doesn't have to be exactly that way yours is pretty similar just need to incorporate the text! :) But it is a very slick skin, but if you have never seen the VDR Frontend you don't know what it is all about anyways! :) so get ya a client setup! :) Of course you have to run Streamdev-server on the VDR server, but I assume you are anyways! :)
Let me know your thoughts.
BTW here are more pics from the Enigma Skin for the rest of the VDR Frontend:
http://www.vdrskins.org/vdrskins/thumbnails.php?album=41
I don't actually use the theme they use, I use the Dark-Blue theme which makes the window more transparent. Maybe I will take some screen shots of mine sometime. But it is a slick skin I think.
And NOW do you understand why I asked about some sort of GUI when you pause and a timeline etc? I am spoiled! :)
Hi,
at first, thank you for your really great work. ;D
Personally I would be glad to watch JPEGs and listen to MP3 via the MVP, possibly via NFS or a stream. I would also like to take part in developing it. But first I've to finish my move to a new flat.
Another suggestion is implement the vompserver as fully functional output-device for the vdr, which means that the vdr states what do display on the OSD directly. This would have the advantage that one can use all the beautifull plug-ins of the vdr, e.g. playing back dvds or (s)vcds, directly.
A more theoretical question is whether it is possible to connect more then one server at the same time. E.g. recording a on server A and recordings b and c on server B.
Can anybody guess how difficult it would be to change the handling on the server's side to UTF-8 if and only if the utf8-patch to the vdr is used, which keeps the names of the recordings under linux itself readable. Probably one can change the encoding of strings in the vompserver-plugin to the iso8859-1 enconding if the patch has been found.
BTW.: We've got a WLAN router working which offers/has to offer DHCP. I've noticed that the MVP connects mostly if and only if it's got its ip from the router and the dongle.bin from - obviously - the pc. Otherwise it tries to connect the vdr until the judgement day.
Has anybody noticed the same or even better has a solution to this problem? ???
Hi again,
I've just forgotten. Even if the box tries to connect infinitely I can connect the box via telnet and can e.g. restart the vomplient with debugging enabled. Btw. it states it tries to reach a server.
Torsten
Quote from: torsten on August 24, 2005, 14:17:26
Personally I would be glad to watch JPEGs and listen to MP3 via the MVP, possibly via NFS or a stream.
I would lke to have these both features, too. But I also think Chris is right when he wants to finish all the tv/recordings-stuff first.
Quote from: torsten on August 24, 2005, 14:17:26Another suggestion is implement the vompserver as fully functional output-device for the vdr, which means that the vdr states what do display on the OSD directly. This would have the advantage that one can use all the beautifull plug-ins of the vdr, e.g. playing back dvds or (s)vcds, directly.
This suggestion already exists: Take a look at the old "mvp"-plugin by Dominic Morris. [NOT the "mediamvp"-plugin]. He discontinued the development of the output-device-plugin because of the big disadvantage: you can only use one MediaMVP. With the mediamvp-plugin here actually work 4 MediaMVPs simultaneous.
QuoteCan anybody guess how difficult it would be to change the handling on the server's side to UTF-8 if and only if the utf8-patch to the vdr is used, which keeps the names of the recordings under linux itself readable. Probably one can change the encoding of strings in the vompserver-plugin to the iso8859-1 enconding if the patch has been found.
Not quite sure what you mean bout not being readable. If you are referring to being able to access the Files via Windows or something, due to the default naming scheme by VDR you can start VDR with the option
VFAT = 1 or add it to your
Make.config and it will name the directories etc as such with supported characters.
Jpegs, Gifs etc would be nice, considering the MVP originally was designed to do such and play AVI's etc I think the capability will be there someday. I am sure Chris is just trying to do each option in steps to make sure there aren't too many problems to diagnose at once continuing in a never ending loop! :) I am not sure how much memory the MVP actually has in its capability to run some sort of Xine Client etc to connect to VDR for full VDR functionality, but that is what I am hoping for to in the end game. I currently use either a Laptop or an XBOX to act as a VDR Client and have full functionality with VDR OSD etc. The Xine over Network might be the answer to this. I honsestly have only played with it in the early stages, and haven't had time to get back to it since. I use full VDR in Client mode with Streamdev and XINE currently. As where the Xine over Network doesn't need VDR on the client side at all. So being as such it might be possible to someday have it be part of the MVP OS being as I understand it being a mini linux afterall!
I only have the one MVP currently since I ordered it for testing, but now plan on ordering a couple of more, but definately want multiple MVP capability without having to run multiple VDR threads. Being as you can already do this with multiple clients via Streamdev-Client I would think this is attainable but again I am not the programmer! :)
I do look forward to somehow letting the MVP attain its IP from a regular router and be able to get the Dongle.bin via multicast or whatever as the MVPServer does, for my testing only so far I had to setup a regular DHCP server and add the MVP to it. I would like to get away from that so that I can let the router handle that. But it was easy enuf to do so I am not complaining! :)
First I want to say, that I'm impressed by the work done here. Vomp is actually my favorite - I tried all others, and none satisfied me more than vomp ;D
Very very very good work - faster boot than any other MVP client, fast connect to server. Stable for me with some minor faults (picture disruptions by using forward and backward buttons).
Some things that may be improved if there is time for it: a) time to load channel list is very long (for me: 25 seconds [1245 channels, because I'm too lazy to work on my channel list - just copying]) - b) vomp dies if channel is not available - c) initial volume is always max on starting (startup parameter ?) - d) channel switching while showing OSD
But I agree with Chris, there are things much more important than these to work on (EPG..).
Again - great server - keep on.
@Hoochster: there is a way to make it work without a full dhcp-server. I use the standard dhcp-server of my router and then I use mvploader to provide the dongle for the MVP. Works like a charm. Here the link for this piece of software: http://www.vdr-wiki.de/wiki/index.php/Mvploader
My config: gen2vdr-RC3, vdr-1.3.27, dongle 0.0.8, FF-DVB-S 1.5 & 1.6
Quote from: Schnurps on August 24, 2005, 14:26:45
Quote from: torsten on August 24, 2005, 14:17:26
Personally I would be glad to watch JPEGs and listen to MP3 via the MVP, possibly via NFS or a stream.
I would lke to have these both features, too. But I also think Chris is right when he wants to finish all the tv/recordings-stuff first.
That's right. Just a kind of looking in to the future ;D
Quote from: Schnurps on August 24, 2005, 14:26:45
Quote from: torsten on August 24, 2005, 14:17:26Another suggestion is implement the vompserver as fully functional output-device for the vdr, which means that the vdr states what do display on the OSD directly. This would have the advantage that one can use all the beautifull plug-ins of the vdr, e.g. playing back dvds or (s)vcds, directly.
This suggestion already exists: Take a look at the old "mvp"-plugin by Dominic Morris. [NOT the "mediamvp"-plugin]. He discontinued the development of the output-device-plugin because of the big disadvantage: you can only use one MediaMVP. With the mediamvp-plugin here actually work 4 MediaMVPs simultaneous.
Haven't heared about it. I will have a look and come surely back to vomp ;)
Quote from: Hoochster on August 24, 2005, 14:55:21
QuoteCan anybody guess how difficult it would be to change the handling on the server's side to UTF-8 if and only if the utf8-patch to the vdr is used, which keeps the names of the recordings under linux itself readable. Probably one can change the encoding of strings in the vompserver-plugin to the iso8859-1 enconding if the patch has been found.
Not quite sure what you mean bout not being readable. If you are referring to being able to access the Files via Windows or something, due to the default naming scheme by VDR you can start VDR with the option VFAT = 1 or add it to your Make.config and it will name the directories etc as such with supported characters.
My linux-box uses utf-8 as encoding for its filesystems. So i used the so called utf8 patch to vdr to keep my recordings in the filesystem readable. In fact german character in iso8859-1 aren't really readable for humans if they are interpreted by the system as utf8. With the patch vdr itself and the filenames in the ext3-partition are fully human-readable.
In a couple of days I will have a closer look to the utf8-patch myself and try to make CVS-version of the vompserver compatible to it. We'll see whether it'll work.
Quote from: Hoochster on August 24, 2005, 14:55:21
Jpegs, Gifs etc would be nice, considering the MVP originally was designed to do such and play AVI's etc I think the capability will be there someday. I am sure Chris is just trying to do each option in steps to make sure there aren't too many problems to diagnose at once continuing in a never ending loop! :) I am not sure how much memory the MVP actually has in its capability to run some sort of Xine Client etc to connect to VDR for full VDR functionality, but that is what I am hoping for to in the end game. I currently use either a Laptop or an XBOX to act as a VDR Client and have full functionality with VDR OSD etc. The Xine over Network might be the answer to this. I honsestly have only played with it in the early stages, and haven't had time to get back to it since. I use full VDR in Client mode with Streamdev and XINE currently. As where the Xine over Network doesn't need VDR on the client side at all. So being as such it might be possible to someday have it be part of the MVP OS being as I understand it being a mini linux afterall!
First the box has only 16MB for the linux system. Second I do not think that it will be fast enough to make the recoding itself. :( I think it must be done on the server.
Thanks AronSira, will look into it!
Wow, so much to reply to, and so little time... The issue about DHCP and booting the MVP, what does the MVPLoader actually do? The problem with routers giving out IP addresses is that a router can't tell the MVP the IP address of the TFTP server. I havn't experimented with what the MVP does if this information is not there, but it sounds like it does something?
Unless the MVP does something intelligent if it isn't given a TFTP server address there's nothing vomp can do about it.
Quote from: AronSira on August 25, 2005, 09:14:23
First I want to say, that I'm impressed by the work done here. Vomp is actually my favorite - I tried all others, and none satisfied me more than vomp ;D
Very very very good work - faster boot than any other MVP client, fast connect to server. Stable for me with some minor faults (picture disruptions by using forward and backward buttons).
Some things that may be improved if there is time for it: a) time to load channel list is very long (for me: 25 seconds [1245 channels, because I'm too lazy to work on my channel list - just copying]) - b) vomp dies if channel is not available - c) initial volume is always max on starting (startup parameter ?) - d) channel switching while showing OSD
But I agree with Chris, there are things much more important than these to work on (EPG..).
Again - great server - keep on.
@Hoochster: there is a way to make it work without a full dhcp-server. I use the standard dhcp-server of my router and then I use mvploader to provide the dongle for the MVP. Works like a charm. Here the link for this piece of software: http://www.vdr-wiki.de/wiki/index.php/Mvploader
My config: gen2vdr-RC3, vdr-1.3.27, dongle 0.0.8, FF-DVB-S 1.5 & 1.6
Thanks for the comments, always nice to hear someone likes it!
As for your could-be-betters:
A) 25 seconds is ridiculous. I will look into what is happening.
B) It shouldn't die if the channel is unavailable. Does it just go to a black screen? What kind of unavailable is it? VDR recording something else, channel not being transmitted?
C) Initial volume is something that will go in as a configuration option. That one is listed on the SourceForge RFE too :)
D) When I get the EPG into that box I will make OK change channel. Otherwise press back to get rid of the box and then change channel. New remote users will have enough buttons to be able to have the option of scrolling through the EPG or changing channel.
Ya, mine is long on the channel list too, but I wasn't gonna complain after you had to mod the gui to show it in the first place! :)
As far as the DHCP thing, I will be trying the MVPLOADER this afternoon, but basically as you said the MVP has to know where to get its Firmware from, the original software for the MVP setup a Broadcast server that the MVP knew to look for to get the firmware. The Standalone MVP Server has an MVPLOADER that does essentially the same thing, resulting in not needing a seperate DHCP server. But the MVP Plugin and Vomp Plugin as default require some sort of Broadcast server to send out the info or do as we have been by building a standalone DHCP server for the process. I am guessing someone was able to take the MVPLoader part out of the standalone server and make it where it will run by itself. Which is great! That way people don't have to do away with their router/dhcp servers!
Now that I have installed and evaluated VOMP, I have to say that I am impressed. The possibility to develop the dongle file and the server (plugin) all by himself gives the programmer a lot of advantages. I will also take a look at the VOMP development environment.
That drove me to a new idea for VOMP. When I power up my satellite receiver I always get a live picture showing the last selected channel. I think that this should also be possible with VOMP. There could be a selection menu where one could select either the OSD or the Live-TV to be shown after start.
While the MediaMVP should not only be a frontend for a satellite receiver, but also a general purpose multimedia player, there could also be other options in the menu, e.g. DVD, video or MP3 library. This would give the user the possibility to configure the default behavior of its MediaMVP, e.g. for being a DVD player.
I ask myself if this would be a big issue to implement. ;)
VDR 1.3.30 introduced a new framework to allow plugins to interact directly, rather than through VDR. This may eventually provide a method of implementing new features, so for example instead of vomp playing MP3 files directly it calls the MP3-player plugin.
In the meantime though I agree that the important thing is to get the basic set-top-box and PVR functions working.
Dave
Radiofreak, you are right, developing both client and server myself allows me to do pretty much anything I want that is within my programming ability... (And the daft limitations of the MVP). However it does mean that development is slower because I'm working from scratch. It's swings and roundabouts, for anyone who understands that expression! I have added your startup idea to the Request For Enhancements list on the SourceForge site. My views on the general media player aspect of the MVP are already on here, but I have to say that the possibility of playing a DVD through it interests me. Which is a bit stupid as it would be the most complex one to code with all that menu system DVDs have. Anyway, that's a long way down my list! :)
Hello Chris
ad dies: I don't know actually whether it dies, but you are right - the screen gets blank, but additionally the MVP does not react any more ???. So for me the only way to get it back working is to unplug and switch it on again ;).
I will also take a look at the developement environment and try to understand implementation there ..
Thx,
Robert
@AronSira:
Have you tried to telnet the box and to log in as root?
If can log in then you can check via linux ps command whether the client still works. You can restart it yourself. It resides in the root directory of the box. It will be more verbous if start it with the -d option.
Torsten
Thanks torsten,
I will try this asap (currently at work ;)) and post my findings.
Have a nice day
It sounds like the client is exiting to me. If the screen ever goes black like that the client is waiting for data transfer from the server. If that doesn't come, and you press the back button, the client will return to the menu after the TCP timeout time. Which is either 10 or 30 seconds I think. If pressing back and waiting doesn't do it, the client is probably dead. The only other thing that could cause unresponsiveness is threads deadlocking, but I don't think that will happen playing live tv.
I have thought about making an option to vompclient that makes it boot up and show a message like "Sorry, I crashed" etc. Then the startup script could loop and run vompclient again. But there are negative points about that idea too. Hmm!
Hello Chris
.. first of all - sorry for the delay :'(.
My channel unavailability is, that I have a channl in my list, that has moved to another transponder (maybe it has even moved from Astra to Hotbird) - so the channel definition is no more valid.
As for me the back/exit button does not work any more (and any other button).
But as torsten told me, I telneted to the box - and it it was all alive.
I restarted the vompclient manually and it worked again ::).
But surprisingly something happened I never thought about: I pressed the LiveTV button and my channel list was there - elapsed time: incapable of measurement ;D - it was this fast ;D. What I could see at the telnet window: every channel was listed at the telnet window.
Just could not believe it and retried it 3 times: faster as fast! ;D ;D ;D
I hope this helps (I did not find the time to try to set up a developemnet environment for the client and thus had no possibility to take a quick look at the code): output at the telnet windows is eg:
here 1186 RADIO PLUS
here 1187 RMF Classic
here 1188 Jedynka - PR
here 1189 Trójka - PR
here 1190 RTL RADIO
here 1191 OE3
here 1192 OE2 Tirol
here 1193 OE1
here 1194 OE2 Wien
here 1195 OE2 Niederösterreich
here 1196 OE2 Burgenland
here 1197 OE2 Oberösterreich
here 1198 OE2 Salzburg
here 1199 OE2 Vorarlberg
here 1200 OE2 Steiermark
here 1201 OE2 Kärnten
here 1202 FM4
Does the client not return to the command line (init does not end, but stop at /vompclient) ? ???
Thx again for this great piece of software (I'm sure this will become #1 for VDR users 8))
Robert
I think I know what is happening with the long channel listings. If I'm right, it's a printf line I left in the program by mistake for dongle 0.0.8 - it seems that if the program is started by init and friends, and then it starts printfing lots, at some point it pauses for a while. It should only happen the once I think, further channel listings should be quick. Which I think is what you are saying AronSira..?
Sorry, but it's only quick when vompclient is started manually.
When started by init it's always slow.