Messages

Chris, IIRC you told me that the phonon stuff doesn't work if you're not running the full KDE. On Debian / Ubuntu, at least.

The bug below has just been fixed in Debian. Not sure if it's relevant, but people have commented in it about phonon not working if you've never started a KDE4 session.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498573

There's even the possibility to get it working without having to start kde4 (tested under ubuntu 8.10); I got the hint from the debian bugreport above.

Code Select Expand

export QT_PLUGIN_PATH=/usr/lib/kde4/plugins/
./qtvomp


Is there anywhere to send Beer etc to encourage the development process along? :->

Good idea! I'm willing to donate, too. Paypal, postbox, anything? 

Hi folks,

it's me again, now back with my D3 exchanged to a H4. But.... 
For the record, it's a MVP 86020 LF Rev H4 Lot 3908, Rev. 2.06 (on boot screen) with coaxial SPDIF.
Currently I'm running vomp-dongle-0.3.0-2-Yaris with the correspondig server plugin.

Yesterday, I connected it to my TV an started it, but it looped endlessly trying to boot. Sure thing, I had to increase the version number in vomp-dongle.bin.ver. I did this using the script from http://www.vdr-wiki.de/wiki/index.php/MediaMVP_-_create-dongle-bin-ver
Then it booted fine and ran flawlessly for an hour or so. (btw, I got a complete packaged MVP with new remote in turn of my broken D3  - nice of Hauppauge [after keeping me waiting for 2 and a half months...]

Well, but obviously I was too confident... I wanted to test how fast the MVP would boot from flash and selected reboot...
The first time it still got as far as "Loading Application" (afair), but the next time I got stuck with "Checking Ethernet Connectivity", getting no link on MVP and switchport.
When I disconnect it long enough (hours?) from mains, it still sometimes gets up to "Loading Application", but after a few minutes, the screen goes black and it falls back to "Checking Ethernet Connectivity"....
I even tried with another switch (in fact in place of my currently working D3A), but with no success.

What the heck happened here? Was the flash written badly somehow? And I have no idea how to reset the box (besides soldering a serial port and intercepting the boot, OK...  but I'm not so brave when it comes to soldering on SMD-boards...)

Update:
I just powered it up again (after some hours) and managed to get to "Contacting servers...". My vompserver.log said the following:

Code Select Expand

20:12:56.693986 [debug]  MVPRelay - MVPRelay request from 10.0.0.12
20:12:56.694186 [debug]  MVPRelay - Sending my IP as a000003
20:13:01.423193 [debug]  Client - Received chan=3 kats=1225912381
20:13:01.438942 [debug]  Client - Waiting
20:13:01.755435 [debug]  MVPRelay - MVPRelay request from 10.0.0.12
20:13:01.755601 [debug]  MVPRelay - Sending my IP as a000003
20:13:02.003847 [debug]  MVPRelay - MVPRelay request from 10.0.0.12
20:13:02.004015 [debug]  MVPRelay - Sending my IP as a000003
20:13:03.513926 [debug]  Tftpd - Wait finished
20:13:03.514072 [debug]  TftpClient - Client handler started
20:13:03.514215 [debug]  Tftpd - Starting wait
20:13:03.514317 [debug]  TftpClient - RRQ received for dongle.bin.ver
20:13:03.514397 [info]   TftpClient - File: '/usr/share/vdr-plugin-vompserver/dongle.bin.ver'
20:13:03.514482 [info]   TftpClient - threadMethod terminating connection
20:13:07.459839 [debug]  Client - Received chan=3 kats=1225912387
20:13:07.475584 [debug]  Client - Waiting
20:13:13.387336 [debug]  Client - Received chan=3 kats=1225912393
20:13:13.406987 [debug]  Client - Waiting
20:13:13.505800 [debug]  Tftpd - Wait finished
20:13:13.505967 [debug]  TftpClient - Client handler started
20:13:13.506407 [debug]  Tftpd - Starting wait
20:13:13.506528 [debug]  TftpClient - RRQ received for dongle.bin.ver
20:13:13.506630 [info]   TftpClient - File: '/usr/share/vdr-plugin-vompserver/dongle.bin.ver'
20:13:13.506713 [info]   TftpClient - threadMethod terminating connection
20:13:18.505742 [debug]  Tftpd - Wait finished
20:13:18.505921 [debug]  TftpClient - Client handler started
20:13:18.506170 [debug]  Tftpd - Starting wait
20:13:18.506280 [debug]  TftpClient - RRQ received for dongle.bin.ver
20:13:18.506419 [info]   TftpClient - File: '/usr/share/vdr-plugin-vompserver/dongle.bin.ver'
20:13:18.506514 [info]   TftpClient - threadMethod terminating connection

(The "Client - Received" messages originate from my second mvp)
I tried to update ther vom-dongle.bin.ver, but didn't manage in time. And the box hung again...
After a power reset I get the same result as above (as the subjet says...)

Hi folks,
good news: the broken remote works again! 
I replaced the IR LED and now it works like a charm. Hannon from DALnet:#electronics noticed something yellowish in the old LED and advised my to replace it.
So for all of you with a broken remote, that might be a solution.
Thanks all of you for your help anyways! 

BTW, I used the IR LED part number CQY99 from Reichelt Elektronik, if someone needs to know (I had it lying around fortunately): http://www.reichelt.de/?;ACTION=3;LA=4;GROUP=A54;GROUPID=3045;ARTICLE=6832;START=0;SORT=artnr;OFFSET=16;SID=29ZjO496wQAR0AACntaSI18b46ac32b19a7cabe78262b44486880

Here's my wish-/buglist:

• jumpplay: start playback at the beginning if there's an odd number of marks (e.g. a missing 1st mark) or better check if the first mark is at the end of the recording. Background: there are some recordings where playblack immediatly stops since jumpplay directly jumps to the the end if the first mark is there (actually a noad  problem which annoys in vdr with jumpplay, too...)
• live tv: skipping unavailable channels caused through exhaustion of available transponders like in vdr
• a working radio epg (currently the epg list jumps to the first tv channel)
• programming of radio timers
• the name of manual timers of an channel without epg should be the channel name, not the standard description "No information available", maybe the definition of the actual timer values should be possible

Anyways, a wonderful peace of work :-)

Yeah, J1 is something I thought of at first, too. But I rather think it's some kind of overvoltage protection (maybe a zener diode or rather a fuse), since it's right between the battery's positive pole and the circuit (except the IR diode's anode).

Thanks for your efforts, Marten.
I couldn't find that MAGIC chip either... But what about the component X1 on the back? What's that, anyway? A quartz? I have no idea, i have to admit. But it obviously directly connects to the MAGIC, so I thought about an external clock source or something like that. If this changed it's frequency? But that's only some very rough guessing of someone not so firm in electronics...

Edit: xmode2 output of the two remotes attached, maybe that shades some light on the case 

Edit2 (yeah, I have nothing to do ): A photograph of my other remote - the one that works again and obviously changed codes. There are some different parts on the board, but the layout seems the same.

Hi Marten,
I opened my old style remote (the one which stopped working after reviving the old one) and photographed back and front of the board. Perhaps you or someone else is interested 

Hi Stuart,
some parallels here, as my now again working remote also changed codes.
But the most esoteric thing is that the "new" remote obviously stopped working after reviving my old one... somewhat frightening...

Hi Lodda,
I'll give it a try

Look into vomp/dongle/tofs/etc/rcS and edit the last line into "/vompclient -s 10.0.0.3" (where 10.0.0.3 is your VDR server's IP)
Now do a ./build in the dongle directory, and there's your new vomp-dongle.

For testing you could also telnet to your mvp, "killall vompclient" and start "/vompclient -s IP" manually

@Chris: This must have been telepathy

Something very strange is happening here... But from the beginning:
Yesterday I got a "new" MVP... well, unluckily it's a D3... but that's another story.

The first thing I tried was to use the remote from the new MVP (which is the "old" style) with my faulty MVP (see my last posts).
Funny enough, it seemed to work partly (at least channel up/down, ok and the numbers) and only from a very short distance. I thought "hey, so it was the damn remote"... hmm, let's first go on.
The next thing I tried was to record the new unit's remote with irrecord... strange things happened here: it was discovered as RC-6, but detection ended in error when it didn't recognize a toggle bit. (Which is what still happens, BTW) Update: it's still recognized as RC-6, but with unknown encoding (so it records in raw mode)

Now comes the real surprise: out of fun, I tried my old remote. And it worked!? And still does...
Accidently I found out that my old remote that is working now is recognized by completely different codes by lirc (namely the "modern remote bundled with haupauges Nexus DVB-Card").

What the heck happened here? Can anybody save me from insanity? I really don't understand things anymore... 

Hi Chris!
Thank you very much for your immediate response. I finally managed setting up a dev environment again, thanks to your perfectly working script.

I put in some logging in remotemvp.cc in methods RemoteMVP::getButtonPress and RemoteMVP::init. The device gets opened nicely (devName=/dev/rawir, device=3), however the only message I get regarding the remote is the worker thread calling getButtonPress with waitType=2 and select(device + 1, &readfds, NULL, NULL, &tv) resulting in NA_NONE.
Again, no reaction to keypresses on the remote, not even a single message in the log.

I also tried several versions: the current cvs (with my debugging), the latest yaris-patch and the stable 0.2.7 release, but no luck. I even tried several other RC5 remotes, in case the MVP's one got crazy...
My last struggle was to try and get the device working with Hauppauges original (crappy) software... no luck. Well, in fact I can't even remember I have ever gotten it working this way. May be because of the bad state of that old W2K installation...

Furthermore, I didn't find any code that toggles the LED on reception of IR signals, so this seems to be hardwired.


Edit:
I attached the lirc-config of my (maybe faulty) remote. However, according to http://lirc.sourceforge.net/remotes/hauppauge/lircd.conf.hauppauge my recorded codes seem to be ok, at least compared to some codes of the "Hauppauge" remote (the first section in the link).
Funny enough, I have that remote here (the black one included with the Nexus-S); however I can't remember if it worked with the mediamvp (at least partly). So I have no real confirmation if the codes of my current "broken" remote are OK.
Another one had the same problem according to that http://www.shspvr.com/smf/index.php?topic=10679.0, and it obviously was the remote.

Another thing I found out is that the hex-values in the lirc-config correspond to the IR-codes of the mvp... so maybe it's a problem of the mvp itself nevertheless.
BTW, the mvp in fact works flawlessly - if controlled over the UDP interface...

Hi folks,

I seem to have a similar problem. Yesterday, the remote (old style) of my MVP (Rev. D3A) still worked, the other day no more... I used the device about two years up to now and never had similar problems. Currently I'm using vomp-dongle-0.2.7-6.1-Yaris, but the problems persists even with vomp-dongle-0.2.7.
I tried a few things, amongst checking the remote with lirc on a homebrew receiver (irrecord recognizes it as  RC5|CONST_LENGTH, can anybody confirm? And yes, it works there flawlessly). I did this since the LED on the MVP still flashes when pressing a key (also with other RC5 remotes, BTW), but no reaction whatsoever.
I tried some investigation on /dev/rawir... should I get something from that character device when pressing a remote key (by cat'ing to stdout?).
And yes, batteries were the first I checked.
BTW, connection to the vdr is fine, I can supply logs if you want.

I'm at my wits end... has anybody any advice, besides throwing away that amazing device?

Hi Happy New Year!
After hiding the non-VDR data on my video partition from VDR, I had no significant timeouts anymore, and not one crash.
Nevertheless the crashes before were quite strange. Maybe you, Chris, or someone else has some time to investigate?
Thanks!

Hello Chris,

I had to try really hard to reproduce this error now But I finally managed it with Hero *g*
After watching about 15 minutes, I stopped the replay with the stop button, waited about 2 seconds, and restarted it with play (which means resume). Then  about 25 seconds later, vompclient crashed with a segfault. Logs can be found here: http://rafb.net/paste/results/hI4BCz82.html
However, during my tries I noticed that sometimes I just got a timeout message when restarting the recording. Maybe it has something to to with the new code, since I use the cvs-version from sunday. Before I had more crashes, IIRC.

BTW, thanks for your appreciation of my little hack
Maybe it's really just my clumsy use of the video directory. I have a directory named IMAGES in there which contains all sorts of files... maybe I should play a bit with symlinks to hide that from vdr.