Messages

vomp has an own limited - but very functional, stable and fast GUI application. How should the UPnP fit into this?

I got the impression that the Vomp Media player browsed a file system (NFS mounted or locally stored)
If it was then djmount would have made it transparent to Vomp whether UPNP was used or not, since the interface to djmount is the file system.

How about setting up the UPNP protocol on the server plugin? Should also do the trick, but for sure a bit more tricky than on the client.

Vomp client doesn't do any NFS or similar things. Vomp client gets the data directly from the serverplug-in within an own protocol (binary for sure, the client needs to be highly efficient). The server plugin gets the data from the local FS, which could for sure be a mounted NFS directory.
This avoids having a full blown UPNP implementation on the client.

But for sure, some code exists already for the MVPMC project (MythTV as server). Similar project, but different codebase. Only some structures are equal.

Till some months ago, we couldn't use UPNP because of the kernel/compiler dependencies, which is now solved (but still patches are needed for the kernel AFAIK). So basically if you want to have a look into code merge from MVPMC there is a starting point.

Code:
The client has a lot of sourcecode, but not the server. As the server is one side of the protocol, it's much easier to look at and find the relevant things.
I don't think it's too much to read and understand (but for sure I didn't do that yet in detail - I'm not working with the protocol stuff).

Hello Chris,

> - Generating a wscrollbar by refactoring vrecmove
> - Using it in the wtextbox and vrecmove

These I have done now, but I'm at the moment stuck with one decision:

Rethinking how it should look like correctly would be that I implement a scrollableBoxx inherited from boxx with the scrollbar code.
Then the widgets (wtextbox, wselectlist) inherits from this class instead of boxx as only these need atm scrollbarsupport.

But this would be a bigger change and I'm rather for incremental changes than all at once. Especially with these basic classes.

On top comes for me that the extraction of the textcode from boxx into another class should be done first. So boxx is then already very generic before we generate the inherited class scrollableBoxx.

So I would prefer now to have it a bit unfinished from the structure and fix the remaining issues later.

So the steps would be:
1. This patch will be scrollbarsupport within the vClasses (not even the widgets, as the widget classes will have no basic scrollbarcode at the end anyway)
2. Next patch extraction of text functionality from boxx (bigger task for sure)
3. Last patch: Generating the scrollableboxx class and moving the code from the vClasses to this class

What do you think?

I fear at the end you need to be a dictator.
If I need to vote I choose blue.
Just because I will make my brain remember: "This program guide I get from the sky and the sky is blue".

>it would be nice to see it on livetv (green button) and liverecording (red button) too?
I will see what I can do. With liverecording you mean the EPG or what do you mean?

>Is it possiblle to display an smaller scrollbar? Would look smarter
I think it is not the size, but rather the color. Yellow is burning also into my retina .
As I said, "rudimentary" at the moment (and codewise ugly).

Anyway:
Next steps are:
- Generating a wscrollbar by refactoring vrecmove
- Using it in the wtextbox and vrecmove
- Adjusting vinfo to use wtextbox

So it is consistent and is less ugly than currently implemented.

Thx for the comments.

Hello,

as promissed in the wishlist, here the first post of the scrollable EPG description window for review/test/comments.

Usage:
The Dialogbox calculates if the text is too long to fit on the screen and in case it is longer it displays a (rudimentary) scrollbar and you can scroll with the up- and down-keys on the remote.

If you have questions, just let me know.

Philipp

edit: removed patch as new one is available

What do you mean by support "like Streamdev"?

DVB -> vdr -> streamdevserver -> streamdevclient -> vdr -> vompserver -> MVP ?

This setup I have in my dev environment already.

If SVDRP is used, it is not. http://www.linuxtv.org/vdrwiki/index.php/Svdrp

AFAIK: Vomp doesn't use SVDRP at all. It's directly linked to the vdr-libs as a plugin.

2. To be able to scroll epg description if it's too big for the box.  (I use the Radio Times listings, and they can go on a bit.)

5. Scrolling long epg-descriptions

Before doing double work, I would like to tell that I have a nearly finished implementation done yesterday. Cleanup and polishing still open.
Please expect this or latest next week the patch for review.

Philipp

Arg,

you are right. I uploaded the old one twice. Now attached the correct one.

Sorry,

Philipp

I have updated the patch against current CVS.
Also I changed the logic a bit. A check against 0 is ugly (C), so I defined default maximum width with 2000.

(changed: removed wrong patch)

I'm not Betux, so Live TV was working right from the beginning. But 0.2.6 was always crashing when switching to LiveTV.

But the options screen is just always crashing. I have tried now change the decoder, no effect.

I tried now deleting all of the old .conf lying around, so it is not one of the old which are causing the crash, but still it is crashing when leaving the options screen.

Attached is the newly generated one:

Code Select Expand


[General]
Remote keys = H00000209I00000003K25H0000030DI00000003K0DH00000324I00000003K35H00
Last Power State = On

Maybe this helps finding the crashpoint

I'm not Betux, so Live TV was working right from the beginning. But 0.2.6 was always crashing when switching to LiveTV.

But the options screen is just always crashing. I have tried now change the decoder, no effect.

Hello Marten,

can the redesign have an impact on the options screen?
Even not changing anything I get the crash when leaving the options screen.l
Live TV works like a charm.

today I tried to patch an actual cvs-shot with the patches from here: http://www.wellenvogel.de/software/vomp/index.html

It is already in CVS. No need to patch anymore.

The 2 conf files are fine and perfectly works as they should. What is missing is a 3rd conf file.

1. Server-conf. This file is by server and represents what is used for every client (like which dongle to use)
2. Client-conf: This represents what the MVP setup is, like tone

3. (Missing) Group-conf: As soon as we have userprofiles, such a conf file is missing. This file would still be used by every client, but stores config which should be used for different users/groups.

My setup is: 1. client in living room 2. client in parents sleeping room. x clients in childrenrooms (not yet established, but will be when children a old enough)

Now I and my wife would like to see every TV program or functionality, while I would limit (nothing new) the time and programs for my children.

Non of these make sense to store in the serverconfig or clientconfig, as the living room TV is used by every "user". So it needs to be stored in a separate config.

But we still don't have a user profile, so this needs to be implemented first.
With this you will get this additional config automatically and then it will be easy to implement the config there as well.