Hi.
I've released initial version of my OpenMHP plugin at http://users.utu.fi/miknov/vdr-openmhp/ .
The installing is unfortunately cumbersome. It requires pieces of software not available as linux "standards", and for two of them you'll have to register before getting to the downloads.
I've tested the plugin properly only with Xine plugin, and don't know how it'll work with e.g. full featured cards.
Mikko Novaro wrote:
Hi.
I've released initial version of my OpenMHP plugin at http://users.utu.fi/miknov/vdr-openmhp/ .
The installing is unfortunately cumbersome. It requires pieces of software not available as linux "standards", and for two of them you'll have to register before getting to the downloads.
I've tested the plugin properly only with Xine plugin, and don't know how it'll work with e.g. full featured cards.
With Xine I get to the "Ladataan OpenMHP:tä"(Loading OpenMHP) -screen, and it doesn't go further. However, the xlet (YLE's newsticker) is playing on the VNC, but it doesn't seem to get captured to the VDR OSD.
I have ImageMagick 6.2.0.3, is that sufficient?
If yes, how should I debug the problem?
Thanks for the plugin,
Anssi Hannula wrote:
Mikko Novaro wrote:
Hi.
I've released initial version of my OpenMHP plugin at http://users.utu.fi/miknov/vdr-openmhp/ .
The installing is unfortunately cumbersome. It requires pieces of software not available as linux "standards", and for two of them you'll have to register before getting to the downloads.
I've tested the plugin properly only with Xine plugin, and don't know how it'll work with e.g. full featured cards.
With Xine I get to the "Ladataan OpenMHP:tä"(Loading OpenMHP) -screen, and it doesn't go further. However, the xlet (YLE's newsticker) is playing on the VNC, but it doesn't seem to get captured to the VDR OSD.
My mistake. I had wrong path in the $LIB_JAVA.
BTW, the logging $OPENMHP_OUT has wrong path in the exec_java.sh.
Mikko Novaro wrote:
Hi.
I've released initial version of my OpenMHP plugin at http://users.utu.fi/miknov/vdr-openmhp/ .
The installing is unfortunately cumbersome. It requires pieces of software not available as linux "standards", and for two of them you'll have to register before getting to the downloads.
I've tested the plugin properly only with Xine plugin, and don't know how it'll work with e.g. full featured cards.
I've now tested the plugin with xine and full featured card. With FF card (without mem mod) the maximum working size is 66% with 4 bit colors.
The background transparency doesn't work in YLE xlets (even in xine), I get just gray background. However, the transparency of demo xlets does work. Is this expected (your former webpage showed screenshots of YLE xlet transparency working)?
When using mhp-plugin (not openmhp), channel-switching in vdr becomes extremely slow. Is the mhp-plugin doing something on channel-switches? If yes, shouldn't it do the things in background after the channel is switched?
On 7/20/05, Anssi Hannula anssi.hannula@gmail.com wrote:
I've now tested the plugin with xine and full featured card. With FF card (without mem mod) the maximum working size is 66% with 4 bit colors.
And I thought xine with 100% and 8 bit look pretty bad...
The background transparency doesn't work in YLE xlets (even in xine), I get just gray background. However, the transparency of demo xlets does work. Is this expected (your former webpage showed screenshots of YLE xlet transparency working)?
The screenshots were unfortunately a bit misleading. They were taken while using a quickly hacked wrapper AWT toolkit that was lacking in features, which is apparently why the background was left transparent. The filled background seems to be an OpenMHP issue (or then the problem is with the YLE xlets themselves), as it replicates, when running the ticker with plain OpenMHP. I'll have to bring this up with the OpenMHP developer.
When using mhp-plugin (not openmhp), channel-switching in vdr becomes extremely slow. Is the mhp-plugin doing something on channel-switches?
I've been working on the plugin on a pretty slow machine, so this kind of things have gone unnoticed. Well, at least in the cStatusMonitor::ChannelSwitch (at status.c) another thread seems to be created only at the very end, but a closer look would be in order. One thing you might try would be to leave out the xine patch from the plugin, and see if it still behaves similarly.
BTW, the logging $OPENMHP_OUT has wrong path in the exec_java.sh.
Thanks, I'll have to fix that.
I'll be away until next week, so this release was kind of a "hit and run" :)
hi,
a couple of bugs:
- the libopenmhp directory Makefile does not read Make.config (will result in failing in linking if Make.config defines CXX already
- when exiting the MHP applet (or whatever - I press "OK" when the color applet is shown), the system segfaults. A backtrace: (I am using NPTL)
#0 0xb7eb70dd in __deregister_frame () from /lib/libgcc_s.so.1 (gdb) bt #0 0xb7eb70dd in __deregister_frame () from /lib/libgcc_s.so.1 #1 0xb7e858f5 in dl_iterate_phdr () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7eb754f in _Unwind_Find_FDE () from /lib/libgcc_s.so.1 #3 0xb7eb4bff in _Unwind_FindEnclosingFunction () from /lib/libgcc_s.so.1 #4 0xb7eb5830 in _Unwind_RaiseException () from /lib/libgcc_s.so.1 #5 0xb7eb58dd in _Unwind_ForcedUnwind () from /lib/libgcc_s.so.1 #6 0xb7fb953a in _Unwind_ForcedUnwind () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb7fb75a3 in __pthread_unwind () from /lib/tls/i686/cmov/libpthread.so.0 #8 0xb7fb26d8 in sigcancel_handler () from /lib/tls/i686/cmov/libpthread.so.0 #9 <signal handler called> #10 0xffffe410 in __kernel_vsyscall () #11 0xb7e465bb in read () from /lib/tls/i686/cmov/libc.so.6 #12 0xb7de8fd8 in _IO_file_read () from /lib/tls/i686/cmov/libc.so.6 #13 0xb7de848e in _IO_file_underflow () from /lib/tls/i686/cmov/libc.so.6 #14 0xb7dea77d in _IO_default_uflow () from /lib/tls/i686/cmov/libc.so.6 #15 0xb7dea59e in __uflow () from /lib/tls/i686/cmov/libc.so.6 #16 0xb7de48a8 in getc () from /lib/tls/i686/cmov/libc.so.6 #17 0xb7333117 in cXMLParser::ReadSegment (this=0x859fd48, buffer=0x8474df0 "\nmageupdate", bf_size=500) at xml/parser.cpp:41 #18 0xb7333299 in cXMLParser::Parse (this=0x859fd48) at xml/parser.cpp:86 #19 0xb73310e9 in cXMLHandler::RunHandler (this=0x859fd48) at xml/handler.cpp:177 #20 0xb732f0ca in cXlet::Start (this=0x85a52e0, virtualXServer=0xb7333600 "none", virtualXDisplay=10, openmhpOutput=0xb7333b2c "discard") at xlet.cpp:94 #21 0xb732eafe in cXletThread::Action (this=0xfffffffc) at xletthread.c:22 #22 0x080dea50 in cThread::StartThread (Thread=0x837e8d8) at thread.c:227 #23 0xb7fb2ca3 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #24 0xb7e53f5a in clone () from /lib/tls/i686/cmov/libc.so.6
yours, Jouni
Thanks for your comments.
2005/7/22, Jouni Karvo jouni.karvo@tkk.fi:
- the libopenmhp directory Makefile does not read Make.config (will result in failing in linking if Make.config defines CXX already
I'd think that should be fixed by this patch: http://users.utu.fi/miknov/vdr-openmhp/vdr-openmhp-0.0.1b_to_050727.diff
- when exiting the MHP applet (or whatever - I press "OK" when the color applet is shown), the system segfaults. A backtrace: (I am using NPTL)
I was unable to reproduce this problem. I'm still using a 2.4 kernel, so that might make the difference. Does the same thing happen every time? The fault seems pretty curious, since pressing ok *shouldn't* yet actually terminate the java program or the plugin (this is currently done only when hitting "menu") -- or in fact impact the execution in any significant way. What happens, if you press any other keys?
-
Anssi Hannula -
Jouni Karvo -
Mikko Novaro