Testers Needed!

[Chris]

As of this post I have completed my to-do list for the next release of vomp, it is now safe to run as far as I know. Much has changed since the last release and so, I would like anyone who does or could run a bleeding edge cvs version of vomp to have a go and give it some testing.

One thing to note - you will need to copy the l10n directory from the vompserver plugin source directory into the vompserver plugin config directory. To put it another way, in the same directory as your vomp.conf and vomp-mac.conf, there now needs to be the l10n directory.

If you run "cvs upgrade" on the server you will need the "-d" switch to build new directories.

If all goes well I will properly release it in a couple of days.

Thanks!

[sirwio]

Works great so far.
Both dongle and plugin compiled flawlessly. Had some problems though getting the dongle to be downloaded to the client until I realized the new vompserver plugins directory. Moved my existing vomp.conf file to the vompserver plugins directory and the dongle was downloaded just fine.

The new builds will be put under more stress tomorrow when the rest of the family begins watching tv on their boxes...

- Magnus

[muellerph]

Hello Chris,

I'm going to test it, for sure.
And MANY MANY THANKS for spending so much time on this development.

But I also have some thoughts:
A) May you consider adding a versioning string to the protocol?
See: Next version: Numbering scheme and possible more often updated dongles
I would propose to do it in the UDP broadcast as this protocol most probably won't change regardless of how the normal client <-> server protocol is defined.

B) The Patch: Scrolling long EPG description is not included.
I know it doesn't apply cleanly to the latest CVS and I don't have an updated one at the moment. But as this is one of the big ones in the Wishlist, any chance to include it within the next release?
I'm going on vacation with the family this Friday for 2 weeks, so I don't have hope to get it updated within the next 3 weeks.
The changes needed shouldn't be too drastic, but still some work to do - i.e. maybe the new boxstack gives some more troubles to implement cleanly.

Because of B) I would like to have A) implemented. B) is at the end only a small change in the GUI, so with a small update of the dongle we could do a 0.x.y+1 release within a short timeframe.

[muellerph]

Compiled and started fine.

Random issues:
- JPEG showing works, but if I press back box hangs, seems to be same issue as with MP3 - also mentioned in Vomp-Media-Player thread
- Previously it was possible to scroll in live TV through the epg with up and down for the next entries. Is this still possible and in case yes which keys to use?

[Chris]

I have discovered a threading problem in the server plugin. After a few MVP startups (for me anyway) connecting to VDR will stop working. This is now fixed in cvs, please  update and recompile.

Other issues in this thread to follow ...

[hondansx]

Hi Chris,

wow, the new client gui looks really nice. 
One problem so far. My vompserver plugin config directory lies under the mainroot as mentioned here
http://www.loggytronic.com/forum/index.php?topic=335.0

Code: [Select]

/(null)/plugins/vomp/vomp.conf

vdr is starting with -P'vompserver -c vomp'.
Version 0.2.7 did not have this problem.

Another thing:
Waking up the vdrserver with wol is implemented so far. Is there any main reason, why the according shutdownpatch is not implemented from here?

http://www.pompase.net/joomla/index.php?option=com_remository&Itemid=33&func=select&id=5


Many THX,
Walter

 

[davep]

I'm running your 'latest' CVS update, and twice this evening the client has stopped responding to the remote. In each case I opened the 'Timer' menu (which has two entries) then went back to the main menu using the 'Back' button. The problem is that it's not repeatable; I've also been flipping around the menus and watching live and recorded TV for a couple of hours with no problems. There is nothing in the server logs.

I've been tracking the CVS versions for months and this problem has only just occurred.

[Chris]

OK, backing out of a JPEG is now fixed.

@muellerph:

I am guessing you are using an old style remote? I seem to have lost mine, so I am slightly in the dark. Are you finding that up and down are scrolling the now/next data rather than changing channel?

Version info in the protocol: Yes, but I'm not sure about doing it for this version. Fear not though, while this release has taken so long because of the enormous change to the protocol, there is no such blocker for future releases, so they can progress much faster. The same goes for scrolling of EPG descriptions.

@hondansx:

From your other post it looks more like vomp is opening the config file but just not finding that information in it. I'm not sure what your issue is with the config location, what happens when you don't supply the -c parameter? As far as I remember the default location now is [plugins]/vompserver/ for config files.

@davep:

Confirmed. It will be due to my latest BoxStack update. I will look at that next.

[muellerph]

@muellerph:
I am guessing you are using an old style remote? I seem to have lost mine, so I am slightly in the dark. Are you finding that up and down are scrolling the now/next data rather than changing channel?

Yes I have 4 MVPs and 5 old remotes.
The other way round. I can change the channel, but not scroll the now/next data. Would be good to have some keys to use here as I found it useful.
The old behavior was: When now/next data was shown, the up and down was scrolling through them, when there was no now/next it was switching the channels.

Version info in the protocol: Yes, but I'm not sure about doing it for this version. Fear not though, while this release has taken so long because of the enormous change to the protocol, there is no such blocker for future releases, so they can progress much faster. The same goes for scrolling of EPG descriptions.

I was thinking of it and the more I think about it, it should just be an attachment to the name the server sends back when doing the UDP broadcast. Just add 6 digits in brakets which could send the versioning info. I don't think this string needs to be overengineered. So something like "vdr (000208)" for the 0.2.8 could be the answerstring from the server. Future clients would be able to read and compute it, old would just display the version in brakets additionally. Just the server would need to be updated for the moment, the client can use the info in a later step.

@davep:
Confirmed. It will be due to my latest BoxStack update. I will look at that next.

I can confirm as well. I had 0 timer entries.

[hondansx]

Okay leaving out the -c parameter did help to find the vompserver directory.
The -c parameter seems to be ignored.

Walter

[Chris]

muellerph:

The java remote simulator is sending the wrong codes for the old remote, that's why I had it the wrong way around. Can you try the code now, I think it might do what you  want.

[muellerph]

muellerph:
The java remote simulator is sending the wrong codes for the old remote, that's why I had it the wrong way around. Can you try the code now, I think it might do what you  want.

Yes, works now again as expected. Thanks.

[muellerph]

When I get a "channel unavailable", the OSD keeps showing with a black background. So far ok.

But if I then press back, the OSD is removed and I get a black screen.

If I then press "back" again, I come back to the channellist.

This black screen in between is a bit confusing as it rather looks like the box has crashed (which is not the case here).

This happens with TV as well as radio.

[Chris]

The possible hang backing out of the timer list is now fixed, along with the same bug in a handful of other places.

[Chris]

OK, if the channel is unavailable the back button now backs completely out of tv.