Messages

I think the same issue is when displaying a JPEG.

After <back> on a displayed JPEG image the box hangs.

MP3 works with <back>

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.

If this is the case, then I'm going to buy one soon after the release of the sources.

For all interested.
There is now the possibility to directly import from US into EU taxfree as long as the total invoice is below €150,-.
This is for total shipments/imports per day. So don't order 2 things at the same time.

The current price is $179. With taxes, credit card and shipping cost you will get to around $220-225.

With current exchange rate $1,60 per € you get to ~140€.
This is much lower than the €220 you need to pay at the e.g. distributor in Germany.

Yes, at least I'm following this development.

The issue is here that they need to play all files via another application from the NMT. All lists, osd, ... is from the native mvpmc application, but playing the file/data itself is handled by this Syabas application.

So I don't think they are able to have live-tv, they can just play back the recordings.

They constantly request more details about how to play natively, but till now they didn't get any feedback from Syabas.

So yes it would be an HD device in the future, but currently only for recording.

BTW:
In the forum emveepee states "vomp is more a fork of mvpmc and it is another fat client not a server."

Vomp is definitely also a server - as it consists of both client and server as it has it's own protocol..
For VDR the vompserver is (AFAIK) the only 1-n streaming server available. Streamdev-server is only 1-1.

Also:
For sure a simple connection to vompserver will never work without adjusting the protocol used, as the protocol is completely proprietary. Login, listing of recordings, starting a stream and the stream itself (ok, Chris said once the stream itself is similar to streamdev - i haven't touched this code till now)

It's the newer GCC together with the setting that warning should be treated as errors.

At least this is the explanation for the error, but I have no detailed analysis what needs to be changed in order to avoid it.

Does this mean there is a future for Vomp with high definition video, albeit without the Hauppauge MediaMVP hardware? I much prefer the Vomp frontend to VDR's own OSD, but with the transition to high def I was resigned to giving up Vomp at sometime in the near future.

Just guesses /future outlook:
- Vompserver just delivers the mediastream to a client. If this is the case then the only limitation is the performance as this Qt implementation just forwards to the Phonon BE and libxine (AFAIK) supports already HD material. So for Desktop yes
- There will be a streamingclient available where we can do a Phonon similar BE for the hardware available. The NMT is now preliminary support by mvpmc, but I'm unsure about HD material. So there is an existing client already available that we have linux sources for. Details to be analysed and here we will need to do demuxing.
- General: Yes this is the whole purpose of my work: Getting a HD streaming client with additional features like webbrowsing, games, etc.

You might want to consider at an early stage what impact any development might have upon maintaining a front end system that can boot quickly from either a cold or standby state.

I don't think this has to do with the client software in general. This is rather the system setup. Loading/starting the client software just takes few seconds, a cold boot includes always loading the system. So total time starting is only affected by the system, not really the client software.
E.g. Starting the current MVP vomp client just takes about 2s, but the whole reboot with the system takes so long.

Hello,

just wanted to inform you, that I'm currently working on a Qt based client for Vomp-server.
It already logs into server, displays some lists and at the end I can play a MP3 file and hear the sound (sound I hear since 2 days).

As it is just a "technology is basically working" state, I'm not providing code, as public testing results are really not yet useful.
But in case someone is interested in helping getting the code further, then I would search for a place for sharing development/code (I would for sure prefer this site).
It is a "native" Qt implementation, so no code of vompclient is in detail used/copied.

Why Qt:
Longer story. In short I want to have something for Qt Embedded/Qtopia, so in future streaming clients with more RAM than within the MVP I can use the Qt environment for coding, i.e. the WebKit integration is my favorite.
But for the very moment it is just that we have a native Linux client on the normal desktop.
And I worked on KSpread in the past, so I'm used to the Qt way of doing things.

Technically:
It uses the Phonon integration, so it has some ups and downs.
Biggest up is that I don't need to think about demuxing something, the biggest down is at the moment that gstreamer (the Qt integrated Phonon backend) doesn't support the VDR format of MPEG files (live TV I still have to check). But xinelibs (should) support them, so running on KDE (4.x) should solve it.

Why native reprogramming:
I'm definetly impressed by the existing code. It is clean, efficient and effective.
But most of the vomp code handles low level stuff, where Qt offers also solutions. So in detail not much code needed to be reused or can be reused when I anyway program with Qt.
But I know, not all likes Qt...

If you want more info, just let me know.

How many MediaMVP's can work in a 100Mbit wired network?

We have 3 here and don't have any issues. So the question is what may be max?
This for sure depends on the bandwith of the program your are looking.

I would say a 100Mb/s network is find till 70-80Mb/s. And the may we get in Germany via satelite is 8Mb/s at the moment. This would bring us to 7-8 MVPs, but again assuming it is max per channel. If you use DVB-T the bandwith is 3Mb/s so you could have up to 20 - 25MVPs concurrent MVPs.

I'm unsure if anybody would really have such a high number of MVPs at 1 VDR.

Remark to the protocol topic: Maybe better to have a separate thread.

Let me give my comments/ideas:
- Git:
Yes I assume git would fit the development style better. Even that I'm comming from KDE and am used to a central code system, I understand the difference here. I have no experience though with git. Also I don't know where the main git repository should reside to have online access.

- Wiki:
Yes, Chris is currently the only one able to maintain the webpages and Chris time is very limited. So I would vote yes for a wiki. Better than plain HTML pages and very common nowadays.

- Dongles:
Why not hold them on SF? Here we have the possibility to provide different dongles with the possibility to limit upload access already?
The file can then be linked from a wiki.

- Patches:
This is difficult.
Patches should reside when accepted in a repository. How to do this with git I don't know yet (for e.g. an updated dongle), but with CVS it should be in the original tree (BRANCH, for sure not MAIN).
Storing patches maybe on SF, but also a CMS may help here for having the patch collection organized.
I haven't seen a project yet who manages/organizes patches to get a clue how to do it, do you know one?

It's not been that long has it  

No issue with the timing. It's rather that I'm now not sure anymore if it is the right fix.

While I was playing with the scrollbar stuff I assume I got the right clue. There is no need to limit text drawing, as this should be handled automatically by WTextBox (or similar classes). WTextBox drawing is anyway limited by area (as all drawing widgets), so we just need to use the area limitation correctly.

The sad side is that if I only use area the text is drawn in the whole are. So no margin on left/right/top/bottom side.
Okay, we have wtextbox->settestpos, but this only works on top/left, but not on right/bottom (which would be needed for this fix).

So I'm only sure this fix is not really correct, while still thinking about a correct solution.

So not too late, but too late from my side to give these comments.

Anyway, better to have a fix for the drawing error now than to have just ideas for a correct solution

Hello Chris,

currently we have from time to time a new release. No pressure, it will just come when it is ready.

With each version, we normally have changes on the server side of VOMP which means for each release the client needs to be in sync with the server.

Wouldn't it make sense to have more releases on the client side with changes that don't depend on the server or protocol updates?

Like my patch for the scrollable summary, I assume a lot of persons would like to have them in their dongle but for the moment they would need to wait till the next complete release is done. This may take ... till it's ready.

I (or maybe others) would be willing to update the last release with the patches/changes which are:
A) Not depending on server/protocol changes
B) Included in the current cvs version
C) Non intrusive

So bugfixes, translation updates and "known to work" backports would be allowed.

If you (and the other) would agree to this, I would also change the naming scheme.
So 0.x.y would mean:
x: Server/protocol release number
y: client release number

Would this make sense to you?

When I would like to see another issue solved is a support like the Avards-Plugin.

This thread is in german, so I translate the topic:
The Avards-Plugin is use for the automatic recognition and surpression of the black borders when widescreen material is broadcasted in a 4:3 mode (letterbox format). This is done in a way so that the TV gets via the WSS signal a zoom factor.

Some stations are still broadcasting everything in 4:3. Now that I have 2 16:9 TVs this is very ugly. I need to switch on the TV all the time the zoom factor and then I don't see the OSD anymore. So in order to see the OSD I need to toggle the TV setting again.

Also I have the impression, that when we send the compressed signal through the SCART cable and zoom at the TC we get a lower qualtiy then if we already send a zoomed picture through SCART and don't need to do anything on TV.

So it took a bit longer than expected first (family and work and the extended intention).

But here it is.
Changes:
- Scrollbar with new widget wscrollbar
- Use the scrollbar in VInfo and VRecmove
- Using the scrollable EPG in livetv and recordings as well
- Not smaller, rather bigger. But this is now because I use the width of the icons.
- The 2 files are in the tar archive. I have no clue how to do a patch including the files but I'm sure you know how to move them into the client directory

Comment:
The patch is against 0.2.7

It can be applied against CVS but will give one merge error in objects.mk. It's just that the wscrollbar.o is clashing with other new objects in CVS. So should work with minor correction, so I'm not giving another patch. If needed for sure I will give this one too.

Against CVS it compiles and runs, but for sure no VInfo is displayed in livetv (Chris said it already that it doesn't work in CVS atm). So I couldn't test it with current CVS.


Any comments, critics, questions are for sure welcome.

Currently I'm working on the picture viewer (speed, scaling, colour tunig and exif orientation)

This is my favorite and you will be my hero 

Another solution would be to run a Media server and UPNP client on localhost. But I guess the Vomp does not support multiple Media servers?

You can have more than 1 vompserver, but need to choose which one you use at then popping up login screen. This is more or less currently only used for development.

Are you sure there is not multiple protocols, like a telnet/text based protocol for listing media files and a binary protocol for the actual media access?
I believe I have seen a telnet interface in the Vomp code!

I was assuming you meant something like XML transfers. But look at the code, you will see how it is. E.g. you can get a clue here.
The client has the busybox telnet implementation.