Topics

Hi,

just wanted to share some of the statistics which I automatically get from Google. The app doesn't collect any data, only Google does.
There is not a big userbase, for sure can also be the app itself or most using IPhones. Anyway some may be interested:

I did a small fix a week ago, so I can see how many users have recently updated the app:
Version:
New version    37 (6 are from my family)
Previous version   23
(depreciated)   12

The depreciated means most propably lost or broken devices.

Language:
German   53
Englisch   6
Russian   4
Finnish   2
Hebrew   2
(remaining are all 1)

Country:
Germany   54
Ukraine   4
USA     3
Finland   2
Israel    2
Algery   1
France   1
UK            1
Mexico   1
Norway   1

Other info providrd:
I also get Android version, mobile type, which tablet and telecon carrier.

Hello,

as now 3 of my 5 original MVP remotes stopped working, I got a bit afraid and wrote an Android remote app for my MVPs as a fall back solution.

If anybody would be interesting for an Alpha testing, please send me a PN so I can give access to the Alpha testing of Google Play. As far as I understood, that's the way Google normally does it.

I prefer Alpha testing here too as if I would just publish it then people would rate it bad, which wouldn't be needed for an Alpha status.
But if one would like to have the apk, I can send as well.

It is not looking sophisticated and the WAF would be a 2 (when 10 is best), but it does its job and that's all I need to make my children going nuts when the TV program is switching and I'm not even in the room

It is LGPL/GPL and the source can be found on https://code.google.com/p/vomp-remote/, anyway it is so basic that I don't need any license for it at the moment.

It works on my Samsung Galaxy Ace 2, but not on my Samsung Galaxy Tab 3 (known bug in Tab 3 graphics driver).
I didn't try it yet with Windows Vomp client or RaspPi Vomp client.

Any comments or wishes are very welcome.

Hi,

I recently bought me an Apple TV 2 streaming client. I made the jailbreak and installed XBMC for IOS from the GIT trunk tree.
I know this is the VOMP forum, but I'm now searching so long for a device after MediaMVP that I assume a lot of you maybe interested in this report.

Apple TV 2 http://store.apple.com/de/browse/home/shop_ipod/family/apple_tv?mco=MTAyNTQzMzg:

• it's available for €120-130
• has WLAN and ethernet
• has only HDMI port for connection of TV
• has already support for e.g. YouTube

For jailbraking you need a Micro-USB cable (not a Mini-USB). For connection to the TV a HDMI cable is also needed extra.
Jailbraking can be frustrating, as it may not work the first time you try it and you don't know what went wrong. I needed 4 hours, others can do it right with the first try. It's an untethered jailbreak, no connection to pc needed after it.

Installing XBMC is rather easy afterwards, i.e. when you are used to apt-get.

Getting the right XBMC is on the other hand tricky.

For VDR support you need the unstable PVR branch.
For Apple TV 2 support you need the unstable IOS branch.

Both have nightly builds but not the combination. None of both is available in the current stable branch.

One dev was so kind to compile one for us test users so I was able to install and test it.

For VDR you need the VNSI plugin, also available from a GIT tree and must fit to the same PVR branch of XBMC (protocol is still changing).

VOMP and VNSI can work in parallel.

Situation:

• XBMC starts and runs
• Most non video functionality is working as expected with some crashes here and there. So it is still alpha status (did you expect something else?) but already usable for potential shows to satisfy the WAF - legitimate the investment 
• Video: I have no HD card installed, so I cannot test it atm. But HD with H264 is the only format currently supported with hardware acceleration by the box.
  SD is not supported through the accessible hardware (even that the chip should have support for it, it is not accessible through the software library).
  But it is sayed that the CPU should be able to do it in software.
  On my box, it always stutters, through wireless or cable, recordings or live-tv. But this seems to be a known issue, some tell it works for them, some not..
  I have updated to the latest version, changed one setting and can now confirm that SD is working without stuttering as well. But it is not deinterlaced.

What is supported in PVR module:

• Live-TV in fullscreen also with channellist and current epg
• EPG with possibility to set timers
• Recordings, playing, deleting. Markers are not yet supported by the PVR plugin but I'm sure it will be.
• Timer: Set, Edit, Delete, all supported already
• Search: You can search through the EPG for entries

So everything that VOMP has is/will be supported and IMHO much more appealing.
For sure you also have a Linux, Windows and OSX client already available through XBMC normal support. Other IOS hardware (IPad, IPhone) is working similarily.

Performance:
VNSI is as responsive as VOMP is (if you use XBMC on e.g. Windows). The usage on Apple TV 2 is not the same. But I wouldn't say it's way to too slow. Just that you feel some delay here and there but not everywhere. I read some comments that the big areas are already addressed, so huge improvements are not forseen anymore atm.

Now to the bad:

• Development is on Apple only and you need (afaicr) 10.3 at least. So no cheap dev environment possible as long as you don't have a Mac already. No cross compiling possible from Linux or Windows boxes.
• Nothing else than H264, so if you have any HD else than H264 you are lost
• MPEG2 is still a risk, if it will ever be completely without stuttering/buffering unclear, if it will ever be shown deinterlaced
• Jailbreaking maybe not possible in the future anymore in case Apple is really fixing it the hard way
  

If you have any question, I will help answering them or even test them if needed/possible.

Hello,

a) crashes:
I have seldom (~ once a week) crashes with current dongle.
It only happens when playing recordings and pressing intensively 10s and/or 60s foreward or backwards.
I know a log is mandatory, but as it is so seldom, I don't have enabled it yet. Will do when I come to it.

b) Tcp package size:
Currently default tcp package size is 2048. I had for some channels with high bitrates a lot of times stuttering in the tone. Regardless if it was live-tv or if it was playing from recording from a high bitrate channel.
Now that I changed the tcp package size to 4096, these hickups are gone (at least much much more seldom).
As I now assume, the hickups came from network concurrency, would it make sense to increase this default package size to at least 4096?

Hello,

I just recently got the news from the now available Beagle Board.
For US it is $150 and for EU it is currently €103,26 + import VAT taxes.

It is only the bord, so you need powersupply, a box, an IRDA receiver and network on top, but it shouldn't be to costly and involves for sure some practice in building it together.

What makes this board so interesting in comparision to other boxes (like the PopCorn Hour) is that it is fully open and even the drivers are available for HD.
For all other devices I have seen so far either no Linux driver exists or it is so much hidden in the security environment that no direct access is possible.
With HD I'm only unsure about the topic of encrypted data.

It can do only 720p, but personally I think this is enough for HD. I don't own an 1040p plasma.

What do you think?

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.

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?

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

Hello,

just to let you know, how I was setting up my development environment.

I didn't have a DVB-card left, so long time I didn't know how to set up a dev environment for VDR and VOMP for sure I didn't want to touch the running system.
Okay, others may have found the solution earlier, but for me it took months.

Just use a virtual machine and use the streamdev-plugin for your virtual development VDR.

For the virtual machine you can use your most favourate one (VMWare, Bochs, etc.), the only thing it must support is bridged networt, as your MVP need access to the VDR in the virtual machine.

Then you need the dhcpd.conf configured with the "next-server" option. Chris mentions on his Howto "Investigation needed", but it does work.

Attached is my shortened version of /etc/dhcpd.conf:

192.168.178.1 is my gateway to the internet (AVM Fritzbox, dhcp disabled)
192.168.178.10 is my normal VDR
192.168.178.11 is my development VDR
192.168.178.200 is one of my normal MVPs
192.168.178.210 is my development MVP
All PCs get ips form x.x.x.30 to x.x.x.100

Code Select Expand

option domain-name-servers 192.168.178.1;
option subnet-mask 255.255.255.0;
default-lease-time 31600;
max-lease-time 43200;

subnet 192.168.178.0 netmask 255.255.255.0 {
    range 192.168.178.30 192.168.178.100;
    option broadcast-address 192.168.178.255;
    option routers 192.168.178.1;

    host mvp-normal {
        hardware ethernet 00:0D:FE:00:23:FE;
        fixed-address 192.168.178.200;
        filename "vomp-dongle";
    }

    group {
        next-server 192.168.178.11;
        host mvp-dev {
            hardware ethernet 00:0D:FE:00:71:DF;
            fixed-address 192.168.178.210;
            filename "mvp-kernelimage-nfsroot";
            option root-path "/diskless/nfs/mvp";
        }
    }
}


As you can see, the important thing is that you put the next-server option into a "group". Then it works. This is the setup for a NFS dev environment, using dongles is similar.

Streamdev-plugin:
The VDR in your virtual machine will not have a DVB-Card. This is not a big issue. You only need on your normal VDR the streamdev-server plug-in and on your Dev environment the streamdev-client plug-in. How to set it up is your task, but it is no magic.

The only thing is that your purer virtual VDR doesn't have an output device yet, so you should also add the dummy-plugin to your development VDR - otherwise VDR doesn't start (which makes also sense to put it onto your productive VDR in case like me that your only output device is VOMP).

There is for sure one limitation: Streamdev only provides one channel, so you cannot record 2 channels or record and watch another channel. But this doesn't hurt on a dev environment.

Again, maybe nothing new to some of you, but I didn't find any hint yet in the forum about this way of setting up a dev environment.

If you have questions, just let me know.

Hello,

I attached a (small) patch to fix 2 drawing issues:

1. Recordlist: Endings of long recordingnames are not deleted when scrolled http://www.loggytronic.com/forum/index.php?PHPSESSID=8qoviesscgemsrti29so1ekn13&topic=232.0

2. Titlebars: In case the titelbar content is too long, the text had 5 pixels at left end, but not on the right end. Currently wasn't ugly like 1., but I still like it better this way.

How this was fixed:
I added implemented in the drawText function in surface.cc a width check and added the necessary functions with the new argument. All current drawText function still work, as with a width of 0, no length check is done.

Remarks:
1, Currently it is only a width check as I don't think that a height check makes sense
2. I didn't implemented a check for right aligned or centered text yet. Chris: If you want these as well, I will implement it for sure.
3. This check can now be used at other places as well, like for fixing e.g. http://sourceforge.net/tracker/index.php?func=detail&aid=1453263&group_id=139484&atid=743655, but I wait till you say you accept the implementation


(Changed: attachement removed because of new version available)

Hello,

I only have the assumption that currently the screen is always cut left and right. This I only get since 0.2.5.

What I can see is that the TV logo of the channels cannot be displayed completely, so there is missing something left and right.
Also the persons look a bit fat...

I tried to change the possible settings (TV aspect ratio and 16:9 on 4:3 display mode), but no effect on the screen.
I have a 16:9 and a 4:3 TV, and on both I can see this effect.

Does anybody else see this too?

Hello devs,

I'm trying to get into the sources, because maybe you will see later some code.

I tried to interpret as much as I can, but you will better know than I do how difficult this is without any hints.

May you just shortly sum up how the whole setup is, especially how the communication between vomp <-> vompserver <-> vdr is meant to be?
Which classes are the important ones?
For sure I don't need all classes described as at the end the sources will tell the rest.

As always this description should be placed into the respective README in the cvs.

Thanks in advance,

Philipp

PS: To my person:
I'm located in Ottobrunn/Munich, Germany. I worked on KSpread, so I have some experience with C++. I stopped working on KSpread because of lack of time - when my boy was born. Now 3 years later and another 2 daughters we moved into a house and have a full network installed in every room. So a VOMP setup is perfectly fitting.

Now only the functionality and visual impression must be prove to fit the expectations of my wife. So I really intend to work on enhancing VOMP.