Topics

It appears as if the option "16:9 on 4:3 display mode" setting serves dual purposes.

The setting itself suggests that it has to do with how 16:9 resolutions are displayed on a 4:3 TV. It does however appear as if the setting is also used to determine how 4:3 resolutions are displayed on 16:9 TV's.

Perhaps the setting shall be renamed to something more apropriate and that the terminology used for the choices are adopted to the actual chosen TV aspect ratio. The simplest solution may perhaps be introducing another setting named "4:3 on 16:9 display mode"

E.g. choosing "Chop sides" is not really the re-scaling that is done when a 4:3 picture is rescaled to fit a 16:9 display.

I actually missed the possibility to get 4:3 broadcast's to fill the whole screen due to the nomenclature used.

Noticed this behaviour at first while watching some old recordings made in SD but can confirm that its the case while watching live tv as well.

Our tv's are all 16:9 tv's and the vompclient settings are:
[TV]
Widemode = Letterbox
Aspect = 16:9

16:9 HD (720p and 1080i) channels fill the whole tv screen as one would expect but SD channels show something that is more like a 4:3 ratio with big black bars on the sides. If the Wideomode is changed to "Chop Sides" the picture fill the complete tv screen but with a huge overscan. This behaviour is seen on both 704x576i and 720x576i broadcasts.

I have attached a log file where I start out watching a channel in HD (1280x720) resolution and then switching to the same channel in SD (704x576). Note that this is a slightly modified vompclient where I print out the reason for failures in the mp3 audio decoding. It is what I use while troubleshooting the audio chirps described in other posts.

Noteworthy is that the log entry where the VideoType is shown says:
15:30:17.836841 [notice] 2079 Video - VideoType 148 x 2001 i: 1
after the switch. If one choose the channel from the channel list instead one get the correct printout of VideoType 704 x 576!

The same wrong log entry has also been observed while switching from an SD channel to an HD channel. Below is some channel switches made grep'ing only VideoType. Observe the weird resolution 14x480 (Should really be 1280x720).

20:17:32.143785 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:17:38.653976 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:17:44.114826 [notice] 2314 Video - VideoType 1920 x 1080 i: 1
20:18:02.565919 [notice] 2314 Video - VideoType 1920 x 1080 i: 1
20:19:36.850602 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:20:14.184033 [notice] 2314 Video - VideoType 14 x 480 i: 1
20:20:44.583299 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:20:52.330869 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:21:21.655706 [notice] 2314 Video - VideoType 1920 x 1080 i: 1
20:21:59.436071 [notice] 2314 Video - VideoType 720 x 576 i: 1
20:22:24.227793 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:22:31.549092 [notice] 2314 Video - VideoType 720 x 576 i: 1
20:22:36.798217 [notice] 2314 Video - VideoType 720 x 576 i: 1
20:22:47.891242 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:22:54.617073 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:23:16.594869 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:27:06.148200 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:29:50.728992 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:30:07.083192 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:30:33.556668 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:31:10.611470 [notice] 2314 Video - VideoType 1280 x 720 i: 0

With commit 2f7b15598665aacde6010e91f858cdb4f078c764 "Improve cec handling in remote linux" powering off and on is borked.

With the offending commit the TV is turned off but when turned on again it will only display a blank/black picture. There is no way to get the picture back but restoring vompclient.

In head, e.g. commit 7abb2e355d86c592f14d998e47e3594cce0d8a1b, the behaviour is slightly different. When the TV is powered off it turns off for a few seconds but then turns on again but with a no signal picture. Switching to another input source than the pi is connected to and back does give the picture back.

It should be noted that I'm using libcec 2.1.0-1 and not 1.8.1-1 and that the backend is vompserver 0.4.0 so I have patched vdr.cc to be protocol compliant with the vompserver plugin.

What is the reason and rationale behind the cec changes introduced. Would make it easier to troubleshoot. The commit log "Improve cec handling in remote linux" is not so informative :-)

My SD card got boorked some days ago and I have had to write a new image to the card. Unfortunately my notes of the steps required to setup a working develop environment for the vompclient on the raspberry could not be found...

Wouldn't it be nice to have a sticky post on this forum or perhaps even better - a web page on the loggytronic site like http://www.loggytronic.com/vomp-pi.php

These are the steps I took while setting up my new develop environment. It may not be optimal and can likely be simplified - Some parts may be plain wrong. Suggestions and review especially by Marten and Chris are welcome.

Download the "Rasbian Wheezy" image available from http://www.raspberrypi.org/downloads
Write the image to the SD card following e.g. the instructions on http://elinux.org/RPi_Easy_SD_Card_Setup

Boot Rasbian. Remember, the login username is pi and the password is raspberry. When the initial setup loads, change the memory split to give the GPU 128MB. Change other options to suit. Now execute:

Code Select Expand


sudo su -
apt-get install libavformat53 libmagick++5 liblockdev1
wget "http://www.loggytronic.com/dl/libcec1_1.8.1-1_armhf.deb"
dpkg -i libcec1_1.8.1-1_armhf.deb


At this point the box is configured to execute a vompclient raspberry binary.

The libcec development package below does not currently exist in the dl area. It can be downloaded from the forum sections but I suggest adding it to the dl site to make the setup simplified.

Code Select Expand


wget "http://www.loggytronic.com/dl/libcec-dev_1.8.1-1_armhf.deb"
dpkg -i libcec-dev_1.8.1-1_armhf.deb


Next we need to install various development libraries. Please review if these are the correct development libraries. Especially libmagick++-dev brings in tons of dependencies. Perhaps there are a more lightweight version available.

Code Select Expand


apt-get install libavcodec-dev
apt-get install libavformat-dev
apt-get install libmagick++-dev


Install git so that its possible to fetch the vompclient source code:

Code Select Expand


apt-get install git-core


If we continue to build vompclient at this stage the build will choke with a:

g++ -g -O0 -Wall -Wshadow -DDEV -D_GNU_SOURCE -DVOMP_PLATTFORM_RASPBERRY   -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads  -I/usr/include/freetype2 -I/usr/include/ImageMagick  -D__STDC_CONSTANT_MACROS   -c -o osdopenvg.o osdopenvg.cc
In file included from /opt/vc/include/bcm_host.h:50:0,
                 from osdopenvg.cc:36:
/opt/vc/include/interface/vmcs_host/vcgencmd.h:33:52: fatal error: interface/vmc_host/linux/vchost_config.h: No such file or directory
compilation terminated.
make: *** [osdopenvg.o] Error 1

One workaround is to replace line 33 in the file /opt/vc/include/interface/vmcs_host/vcgencmd.h with

Code Select Expand

#include "interface/vmcs_host/linux/vchost_config.h"

A better workaround is likely to add -I/opt/vc/include/interface/vmcs_host/linux to the INCLUDES in the GNumakefile.

exit from the superuser session to fetch and build as user pi

Code Select Expand


exit


Fetch the sources and start the build

Code Select Expand


git clone http://git.vomp.tv/vompclient.git
cd vompclient
make


Congratulation. You should now have a vompclient executable that can be started as:

Code Select Expand


./vompclient


In sweden two channels SVT1 HD and SVT2 HD broadcast in 720p. While watching live broadcast using the vompclient-marten 2013-03-16 (and using previous builds as well) we do observe some micro audio stutter and some not so frequent longer audio breakups. The audio breakups can be as long as a few seconds!

I have uploaded a 1:28 long recording where while watching there was a long audio break at 1:12. During playback using vompclient-raspi or streamdev (to vlc) the playback breaks at 1:12. But if playback is done directly using vlc it plays fine to completion (without audio stutter) as is also the case using playback with vdr-softhddevice.

The recording, 116MB, can be downloaded from here.
http://ubuntuone.com/4nvxpjRVgqSHxruSao2TyL

- Magnus

I noticed on some channels especially HD channels that audio is out of sync (poor lip-sync). Made a recording and tested playback using streamdev and the new samsung smart tv app and playback is correct.

Copied the recording locally to the raspberry where I tested playback using omxplayer with the same result. But when omxplayer was started with --refresh argument the playback is correct with proper lip-synch.

The option --refresh does adjust the framerate/resolution to the video.
>   -r / --refresh                 adjust framerate/resolution to video

I noticed the omxplayer said it adjusted to mode 31 so I changed /boot/config.txt to startup at that resolution. Rebooted and playback was then ok using omxplayer without the --refresh argument. But playback using vompclient is still with poor lip-sync.

Any suggestions on how one can get proper playback/live tv with lip sync?

I makings some test using the vompserver 0-4-0rc branch. My raspi client compiled from 0-4-0rc branch will connect to the vompserver but my old mvp client running 0.3.1 will not.

Do I have anything miss configured or is is a fact that the new protocol and/or new discovery protocol is not compatible with old vomp clients?

Current sources does not compile with libcec version >= 2.0 since it introduces some incompatibilities with previous versions of the api.

The api breaking commit for vompclient can be viewed here:

https://github.com/Pulse-Eight/libcec/commit/3ad0aa0ace71f00f5a972850367e8ae18eae19f5#include/cectypes.h

The change is trivial to implement in remotelinux.cc and remotelinux.h

I suppose that most raspi users are using the prebuild deb packages provided on this forum e.g. version 1.8.1-1

If decided to switch to a later api version we should provide, or give links, to where prebuilt deb package can be downloaded.

Still using a vdr server without ability to record any HD channels I would still like to check the performance of HD playback on the raspberry.

Found a bbc hd recording but it gives bad stutter in audio and playback during playback while it plays back almost flawless using omxplayer (occasional stutter and some pixelation). Since people on this list does not seam to complain on their hd playback I want to rule out its not a fault with the hd recording I have downloaded.

Could someone offer a download link to a hd vdr recording that plays flawless on your raspberry using vompclient.

Did an apt-get update, apt-get upgrade yesterday.

When I now compile head of vompclient-raspi I get the following error:

Code Select Expand


pi@raspberrypi ~/vomp/vompclient-raspi $ make
raspberry normal compiler
Setting up objects
Raspberry pi flags
g++ -g -O0 -Wall -Wshadow -DDEV -D_GNU_SOURCE -DVOMP_PLATTFORM_RASPBERRY   -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads  -I/usr/include/freetype2 -I/usr/include/ImageMagick -D__STDC_CONSTANT_MACROS   -c -o osdopenvg.o osdopenvg.cc
osdopenvg.cc: In member function 'virtual int OsdOpenVG::init(void*)':
osdopenvg.cc:169:68: error: 'graphics_get_display_size' was not declared in this scope
osdopenvg.cc:103:10: warning: unused variable 'video' [-Wunused-variable]
osdopenvg.cc: In member function 'virtual void OsdOpenVG::threadMethod()':
osdopenvg.cc:469:16: warning: unused variable 'waittime' [-Wunused-variable]
osdopenvg.cc: In member function 'unsigned int OsdOpenVG::loadTTchar(cTeletextChar)':
osdopenvg.cc:569:35: error: invalid conversion from 'const VGfloat* {aka const float*}' to 'VGfloat* {aka float*}' [-fpermissive]
/opt/vc/include/VG/openvg.h:680:31: error:   initializing argument 4 of 'void vgSetGlyphToImage(VGFont, VGuint, VGImage, VGfloat*, VGfloat*)' [-fpermissive]
osdopenvg.cc:569:35: error: invalid conversion from 'const VGfloat* {aka const float*}' to 'VGfloat* {aka float*}' [-fpermissive]
/opt/vc/include/VG/openvg.h:680:31: error:   initializing argument 5 of 'void vgSetGlyphToImage(VGFont, VGuint, VGImage, VGfloat*, VGfloat*)' [-fpermissive]
osdopenvg.cc: In member function 'int OsdOpenVG::loadFont(bool)':
osdopenvg.cc:692:10: warning: unused variable 'n_point' [-Wunused-variable]
osdopenvg.cc:693:10: warning: unused variable 'last_cont' [-Wunused-variable]
osdopenvg.cc:749:8: warning: unused variable 'n' [-Wunused-variable]
osdopenvg.cc: In member function 'virtual ImageIndex OsdOpenVG::createJpeg(const char*, int*, int*)':
osdopenvg.cc:1147:7: warning: unused variable 'mem' [-Wunused-variable]
osdopenvg.cc: In member function 'unsigned int OsdOpenVG::handleTask(OpenVGCommand&)':
osdopenvg.cc:1037:1: warning: control reaches end of non-void function [-Wreturn-type]
make: *** [osdopenvg.o] Error 1


The version of gcc reports:

Code Select Expand


pi@raspberrypi ~/vomp/vompclient-raspi $ gcc --version
gcc (Debian 4.6.3-12+rpi1) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

pi@raspberrypi ~/vomp/vompclient-raspi $ g++ --version
g++ (Debian 4.6.3-12+rpi1) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Any suggestions?

Got myself a new TV of the brand Samsung.  As if other parameters like picture quality wasn't enough when buying a TV now one must also check the hdmi cec compatibility. The sales guy was very helpful when I insisted on plugin in my raspberry pi to check hdmi cec compatibility. Running cec-client one could verify that the remote signals where passed to the pi.

Samsungs tradmarked hdmi-cec implementation is called Anynet+. It appears as if their implementation is a bit more to the spec than Philips' that I have explored on another TV in my household.

While firing up vomp I discovered that that while playing back recordings the play,pause,stop,forward,rewind buttons did not work as intended - In fact the TV informed me that they were unsupported!

Did a quick test changing the cec device type broadcasted by vomp from CEC_DEVICE_TYPE_TUNER to CEC_DEVICE_TYPE_RECORDING_DEVICE and got all buttons working as expected.

In fact this makes sense since its would be useless to send e.g. play command to a tuner! Whereas it makes sense on a recording device.

Did also make a quick check changing the type to CEC_DEVICE_TYPE_PLAYBACK_DEVICE and the result of pressing the record button had the TV inform me that it was an unsupported command. Play,pause etc worked fine in this mode.

I suggest changing the type vomp is broadcasting itself as, to be of type CEC_DEVICE_TYPE_RECORDING_DEVICE or make this a configurable setting in the advanced section.

There is only a black screen during playback or live tv. Playback and live tv worked before the following commit:

commit 419964cd6d85419684918774f4ddc420714f616a
Author: Marten Richter <marten.richter@freenet.de>
Date:   Wed Oct 3 22:05:15 2012 +0200

    Switch to OpenVG based OSD, note Teletext and Subtitle rendering not working and little bugs in implementation

I have uploaded a short snippet (57mb) of a recording (Dallas) that can be downloaded from here:
http://ubuntuone.com/1jMt7qGGmdhIQMRNK6R3xJ

The log file from the playback is attached.

Probably unrelated but perhaps an issue as well is that I do see messages like the one below on stderr. These messages does also appear prior to the commit 419964cd6d85419684918774f4ddc420714f616a so I don't think its the problem for me.

[mp3 @ 0x7e3ba0] incorrect frame size

- Magnus

On my Philips TV remote the buttons Channel Up/Down and Skip Left/Right are on the same place on the remote.

While watching recordings we usually skip forward using the Skip Right button to skip the commercials :-). This does however not work on the raspi vompclient with my philips remote.

Could it be that the vompclient need to announce itself as being in different modes depending on where in the UI one are navigating. E.g while watching live tv its obvious that a press on the buttons mentioned above shall result in a Channel Up/Down message whilst in recordings and perhaps elsewhere in the menus one shall receive Skip Left/Right messages.

Sorry if this is totally of bound on how CEC and libcec is supposed to work but I'm a total noob in this area.

Another problem with the remote is that there is no "Record" button making it impossible to set a show from the program guide to be recorded. Any suggested workaround for this?

Been playing around with the git vompserver for the last days (since it is needed to play with vompclient-raspi).
Since my "old" media-mvp dongles are incompatible with the latest git vompserver I has compiled new dongle using head of git as well.

What I do have problem with is that the UI freeze when one exits live tv almost 100% of the times. I must admit that this happens occasionally in my stable rig as well but much, much less frequent.

A bit troublesome is that if one kill all the vompclient processes it will cause a segfault on the vompserver side as well when there has been a freeze.

Attached are two log files. One from the vompclient and then one of the crash of the vompserver.
From the vompclient-freeze log file the first exit was fine but the second failed. The exits where initiated by pressing the stop button (Button 54).

Dongle compiled for the mvp on a fresh installed debian squeeze 32 bit host. Booting the mvp succeeds but once the dongle is loaded there is only a black screen.

The makedevenv scripts used are the latest from git as of yesterday.

Telneting to the mvp reveals that there is no /proc on the filesystem. All other parts appear to be there.

Of course start vompclient will thus fail:

~ # ./vompclient -d
00:17:09.726094 [info]   32 Core - Starting up...
00:17:09.726856 [info]   32 Core - Signal handlers set up successfully
00:17:09.727179 [info]   32 Core - Remote module initialised
00:17:09.727415 [info]   32 Core - LED module initialised
00:17:09.727717 [debug]  32 MTD - Could not open /proc/mtd
00:17:09.727944 [EMERG]  32 Core - Mtd module failed to initialise
00:17:09.728202 [notice] 32 Core - BoxStack module shut down
00:17:09.728465 [notice] 32 Core - Command module shut down
00:17:09.728723 [notice] 32 Core - VDR module shut down
00:17:09.728951 [notice] 32 Core - OSD module shut down
00:17:09.729173 [notice] 32 Core - Audio module shut down
00:17:09.729396 [notice] 32 Core - Video module shut down
00:17:09.729621 [notice] 32 Core - Timers module shut down
00:17:09.729843 [notice] 32 Core - MTD module shut down
00:17:09.730106 [notice] 32 Core - LED module shut down
00:17:09.730368 [notice] 32 Core - Remote module shut down
00:17:09.730597 [notice] 32 Core - WOL module shut down
00:17:09.730841 [notice] 32 Core - Sleeptimer module shut down
00:17:09.731055 [notice] 32 Core - Log module shutting down... bye!

Any clues on what is missing? I tried cross compiling on a debian squeeze 64 bit host first with the same results. Unfortunately my old build environment is gone and I haven't compiled any dongles since late 2006 so I'm a bit rusty in the art of cross compiling.

I'm currently running vompserver 0.3.1 on my backend gentoo server. vdr version is 1.7.25.

On the latest sources, 2012-09-14,  I have commented out the line
setCharset(Osd::getInstance()->charSet());
in vdr.cc to get around the issue of vompclient starting successfully.

I am facing some issues that one wonder is due to not using the current vompserver in git.

Playback of recordings:
* vompclient hangs and get unresponsive if fast forward/rewind is pressed. vompclient have to be killed.

Live tv:
* Only one channel is shown. There are numerous other channels available that are shown on my hauppauge mediamvp clients. The channel shown is the first one in the list.
* Playback of the live tv channel does not give any picture nor sound. The UI is responsive and one can get back to the main menu.

Could the issues above be due to the vompserver version?

I will work on updating the gentoo ebuild to fetch the latest git version but it was a while since I wrote any ebuilds so its not yet functional. Would appreciate if anyone on this list has an ebuild to share!

- Magnus

Hi,

I have now sorted out all problems I see on my H3 mediamvp except one!

If I unplug the power from the unit and imediatelly plug it back the unit will not boot correctly. Of the five grey progress boxes only the first four get filled and the unit hangs forever. If one however leave the unit unplugged for more than 2 minutes the unit boots correctly.

The strange thing is that this behaviour is not present using the mvpmc 0.3.2 dongle wich is based on the 2.4.31 linux kernel. Older mvpmc dongles based on 2.4.17 kernel shows the faulty behavour. Hence my attempt to build a 2.4.31 kernel for use with vomp!

I have tweaked the kernel config file to suit vomp, applied relevant patches and compiled the kernel using the same crosstool as normally used by vomp. The ibm kernel module files are the one present in mvpmc git repository. In previous post I was  told howto retreve this myself and has successfull done so and the two does not differ so I simply using the pre-extracted ones.

The unit successfully boots and vompclient starts but when any button on the remote is pressed the unit crashes. The ir led is initially on but after any keypress its turned off. Starting vompclient with tracing doesn't give any feedback.

Any hints or perhaps even better a solution to my boot problems using the 2.4.17 kernel?

- Magnus

Output of dmesg follows:


~ # dmesg
Linux version 2.4.31-v1.1-hcwmvp (myth@sam) (gcc version 2.95.3 20010315 (release)) #4 Mon Jan 8 08:09:42 CET 2007
IBM Redwood6 (STBx25XX) Platform
Port by MontaVista Software, Inc. (source@mvista.com)
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,9600 ip=:::::eth0:dhcp root=/dev/ram0
Console: colour dummy device 80x25
Calibrating delay loop... 251.49 BogoMIPS
Memory: 13656k available (1112k kernel code, 356k data, 76k init, 0k highmem)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
i2c-core.o: driver i2c-dev dummy driver registered.
i2c-proc.o version 2.6.1 (20010830)
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0xe0040000 (irq = 20) is a 16550A
ttyS01 at 0xe0000000 (irq = 21) is a 16550A
ttyS02 at 0xe0010000 (irq = 22) is a 16550A
PPC 405 watchdog driver v0.5
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
smsc91111 org brcr1 = 0x207cc7b2
smsc91111 (brcr1 = 0x207cc7b2) => TWT cycle = 7
smc91111.c:v1.0saa 08/22/01 by Daris A Nevil (dnevil@snmc.com)
eth0: SMC91C11xFD(r:1) at 0xc2000300 IRQ:27
INTF:<NULL> MEM:8192b NOWAIT:1  ADDR 00:0d:fe:0b:b3:f0
HCW MediaMVP: flash mapping: 100000 at fff00000 to c2002000
Search for id:(20 22ca) interleave(1) type(2)
Search for id:(20 22ca) interleave(1) type(2)
Search for id:(ec46 e6a6) interleave(1) type(2)
Search for id:(20 ca) interleave(2) type(1)
Search for id:(20 ca) interleave(2) type(1)
Search for id:(46 a6) interleave(2) type(1)
Search for id:(ec46 b3c2) interleave(2) type(2)
Search for id:(ec46 b3c2) interleave(2) type(2)
Search for id:(ec46 b3c2) interleave(2) type(2)
JEDEC: Found no HCW MediaMVP device at location zero
HCW MediaMVP: jedec_probe: no known JEDEC part found
HCW MediaMVP: flash mapping: 400000 at ffc00000 to c2002000
Amd/Fujitsu Extended Query Table v1.0 at 0x0040
HCW MediaMVP: JEDEC Device ID is 0xCA. Assuming broken CFI table.
HCW MediaMVP: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
cfi_probe: found redwood_mtd size = 00400000
HCW MediaMVP: cfi_probe: adding [5]parts
Creating 5 MTD partitions on "HCW MediaMVP":
0x00000000-0x002c0000 : "HCW MediaMVP KERN"
0x002c0000-0x003c0000 : "HCW MediaMVP DATA"
0x003c0000-0x003d0000 : "HCW MediaMVP VPD"
0x003d0000-0x003e0000 : "HCW MediaMVP LOGO"
0x003e0000-0x00400000 : "HCW MediaMVP BOOT"
<sdram-mtd>: SDRAM MTD(A0D00000) mapped to c2403000
Creating 2 MTD partitions on "SDRAM MTD Device":
0x00000000-0x00200000 : "HCW MediaMVP ROOT"
0x00200000-0x002ff000 : "HCW MediaMVP OSD"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
eth0:PHY remote fault detected
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.40
IP-Config: Complete:
      device=eth0, addr=192.168.0.40, mask=255.255.255.0, gw=192.168.0.1,
     host=192.168.0.40, domain=sirvio.home, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 963k freed
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 76k init

STBx25xx OS-Core 1.1-Jun/28/2002@June/10/2002 Built Nov 21 2005/20:38:12 for 2.4.31-v1.1-hcwmvp

STBx25xx AV 1.1-July/1/2002@June/10/2002 Built Nov 21 2005/20:38:57 for 2.4.31-v1.1-hcwmvp

IR-Combo for IBM Redwood5 1.0-Apr/17/2002@June/10/2002 Built Nov 21 2005/20:38:57 for 2.4.31-v1.1-hcwmvp
Acer IR mouse installed.

STBx25xx/03xxx GFX 0.1-Jun/26/2002@June/10/2002 Built Nov 21 2005/20:38:25 for 2.4.31-v1.1-hcwmvp

STBx25xx/03xxx Framebuffer 1.01-July/04/2002@June/10/2002 Built Nov 21 2005/20:38:26 for 2.4.31-v1.1-hcwmvp
STB OSD: framebuffer  mapped to 0xc270e000
Console: switching to colour frame buffer device 90x36
fb0: STB OSD frame buffer device
Shared surface handle is set to 0.
~ #

Hi,

I just tried the lastest development script and it now produces a bootable dongle for H3 mediamvp's. The only problem now is figuring out wether PAL or NTSC should be used.

Unforrunatelly as the code in main.cc is written the vompclient exits if it fails to open the /dev/mtd1 device. If I'm not totally misstaken there are no mtd devices on Hx hardware?

Its really easy to patch the source oneself and skip the opening of the /dev/mtd1 device and default to PAL (or NTSC). But it would be much nicer to have a generic solution.

So what would be the best way to solve this problem. Perhaps not bailing out if there is a prblem opening/reading the /dev/mtd1 device and then default to read the value from the conf file and if the value does not exist defauilt to a either PAL or NTSC.

Suggestions welcome

- Magnus

Hi,

I've got an H3 mediamvp successfully running vomp. Its extremely stable if used with the a cvs checkout from 2006-11-11 (cvs update -D 2006-11-11) and the kernel patch mentioned before on this list.

Only thing boothering me now is the boot process. If vompclient is up and running and I unplug the and plug it back imediately the boot process never completes. It dosn't even get to the point of connecting the servers. Only way to get it to boot is to unplug the coord and wait for about two minutes. When power is back the mediamvp boots fine.

The strange thing is that the unit boots as expected if the original hauppauge software is used!!!

I have tried catching the network traffic with wireshark but I'm a beginner analyzing network traffic so if someone has a clue about the problem please let me know. May save me a couple of late nights analyzing network traffic...

The reason I'm investigating this is that I would like to incorporate the functionallity of the mvprelay program into the vompserver plugin. It will ease the  setup for others running H3 boxes.

- Magnus

Hi,

I just realized narrowing down the problems I've seen on my H3 mediamvp that the vompserver code isn't 64 bit compatible. Since a fair amount of my daily work is related to writing and porting code to new platforms I should have seen the fault at once.

The use of long as the type ULONG defined in defines.h is not very portable. The size of long differ between 32 bit platforms (ILP32) and 64 bit platforms (LP64). The long is 32 bits on ILP32 and 64 bits on LP64.

The quick fix for the vompserver is to change the ULONG define to be an unsigned int instead of an unsigned long in defines.h. I recompiled my vompserver, that runs on an 64 bit machine, with this change and voila now livetv, recordings, epg etc works like a charm. Even the windows vompclient began to work!!!

Someone need to go over the code with regard to 64 bit machine compability in mind and post a better patch. I will probably do so over the days but encourage others to work on the issue as well.

- Magnus S.