Messages

Hi,

Could you copy the build error messages here please. What operating system are you compiling on? How is it that you don't have IPv6?


Chris

This is a minor bug-fix release affecting the client only, the server does not need updating and remains at version 0.5.1.

A new thing:

• Radio recording resume

A fix:

• Stopping and immediately resuming a recording fixed. In 0.5.1 it would start at the beginning

Notes:

The Raspberry Pi image is now generated using Pi-Gen: https://github.com/RPi-Distro/pi-gen. The only difference you should notice is the new SSH user name: vomp, and password: vompian.

All the notes in the release announcement for 0.5.1 still apply.

New things:

• It's now possible to mark as recording as new (deleting the resume data)
• The recording information screen displays more details
• When playing a recording, the "previous channel" button rewinds 2s (for interlacing resync (yes, this needs fixing properly))
• IPv6 support (Raspberry Pi only)

Fixes:

• Fixed a playback hang due to a threading deadlock
• Fixed a hang starting playing a recording which has already been deleted on the server
• Fixed the Raspberry Pi screen going black during pause
• Fixed a bug moving a recording with special characters in the name
• Fixed a bug with the advanced menu in options
• Fixed the stop-time display in the timer information screen
• Compile fixes for Stretch and Buster
• Fixed libcec4 support
• Saved some Raspberry Pi CPU usage in the on-screen-display code
• Fixed a crash when using subtitles
• Fixed a crash pressing up too much in the options screen

Other:

• Server Makefile updated
• Server sample config file updated

Notes:

The minimum VDR version is still 1.7.35. The maximum known-working version is 2.4.1.

Raspberry Pi models 1, 2 and early 3s are known to work. Later Pi 3s did not work with the 0.5.0 image but I expect they will work with 0.5.1. I haven't got a late 3, if you have and it works please let me know.

Reportedly the Raspberry Pi 4 has no hardware MPEG2 support. I haven't got a Pi 4 so I can't test it. I expect very bad results trying to play MPEG2! It might still work to play MPEG4, I don't know. It is also possible the image won't work at all - reports welcome!

This is probably the last 0.5.x release. 0.6.x will drop support for Hauppauge MVPs and will require at minimum VDR 2.4.0.

An idea I had... It's no static build but it might be of use. How about compiling a dynamic vompclient then getting the list of so files with "ldd vompclient", copying every single one and the vompclient binary to the target empty O/S and using LD_LIBRARY_PATH to direct it to all the so files? It sounds too simple to work...

Good luck with the Broadcom stuff.

Hi,

For obvious reasons I share your desire to build it statically - I would be able to distribute a much smaller image file and it would boot on a Pi much faster with some kind of Busybox build rather than a whole systemd O/S.

I remember trying it about a month back and got to exactly the same situation you showed. At the time I shelved the idea thinking it would be very difficult / impossible. But, given your post I've had another look... I still think it's going to be very difficult, but maybe not impossible if a mostly static binary is acceptable.

Firstly the warnings - Well they're only warnings - it does imply that it should be possible to have a statically linked vompclient binary with some number of .so files alongside somehow. It depends how many library files "the shared libraries from the glibc version used" means. If it's a few then I would say this is feasible. If it's hundreds - basically a standard /lib & /usr/lib collection, then clearly it's not feasible. I haven't got as far trying this yet.

Secondly - all the libraries used except the Broadcom ones in /opt/vc. I have been working through some of these and it is possible to build some in statically - see the linking script below. The next major set of libraries to tackle is the ImageMagick ones - no small task. I tried making pthread and avcodec static but they eventually depend on one of the Broadcom libs, so they may be possible once the Broadcom problem is solved.

Thirdly - the Broadcom libraries. Broadcom appear to permit redistribution of the libs found in /opt/vc, so including that whole set in an image and dynamically linking to them for me would be acceptable. However, because the .a file versions of those libs aren't available it means any other library you try to make static for vompclient that depends on something in the Broadcom libraries won't link. A second however however, is that it looks like the source code for those libraries in /opt/vc/lib is available (to my surprise) at https://github.com/raspberrypi/userland. If this really is the case then it should be possible to compile the missing .a files, allowing other libraries to then be linked statically.

At best it may be possible to statically link everything except the glibc libraries the warnings are about.

The script below is a work-in-progress. To try it, compile vompclient normally first - this is only the last step linker command. It links what it can statically, and then dynamically links the rest. In theory libs can be moved one by one from dynamic to static. In practice it's quite messy. I think the next bit to work on is the Broadcom libraries, since other libraries end up depending on some low level Pi memory code and they can't be made static until the the Broadcom libraries are.

If you feel like continuing this work please do!

Also if anyone knows a better way of doing any of this, please chip in.

Code Select Expand

#!/bin/bash

set -x

BLOBS="-Wl,--format=binary -Wl,other/vdrhires.png -Wl,other/wallpaper720p.jpg -Wl,other/properties.png -Wl,other/radio.png -Wl,other/timers.png -Wl,other/tv.png -Wl,other/recordings.png -Wl,other/restart.png -Wl,other/hd1080i.png -Wl,other/hd720p.png -Wl,other/sd576i.png -Wl,other/txtoff.png -Wl,other/txton.png -Wl,other/dolbyoff.png -Wl,other/dolbyon.png -Wl,other/recording.png -Wl,other/recfolder.png -Wl,other/defposter.png -Wl,--format=default"
OBJECTS="command.o tcp.o dsock.o thread.o timers.o i18n.o vdp6.o message.o messagequeue.o udp.o wol.o audio.o video.o log.o mutex.o vdr.o recman.o recording.o recinfo.o channel.o rectimer.o event.o directory.o mark.o option.o player.o playerradio.o vfeed.o afeed.o demuxer.o demuxervdr.o demuxerts.o stream.o region.o colour.o boxstack.o boxx.o tbboxx.o vrecording.o vinfo.o vquestion.o vrecordinglist.o vrecordinglistclassic.o vrecordinglistadvanced.o vepgsummary.o vepglistadvanced.o vmute.o vvolume.o vtimerlist.o vtimeredit.o vrecordingmenu.o vchannellist.o vwelcome.o vvideorec.o vepgsettimer.o vchannelselect.o vserverselect.o vconnect.o vepg.o vrecmove.o vradiorec.o vaudioselector.o vscreensaver.o vopts.o wselectlist.o wjpeg.o wsymbol.o wbutton.o wtextbox.o woptionpane.o woptionbox.o wremoteconfig.o wtabbar.o led.o remote.o mtd.o osd.o surface.o vpicturebanner.o abstractoption.o eventdispatcher.o vdrrequestpacket.o vdrresponsepacket.o vvideolivetv.o vsleeptimer.o playerlivetv.o playerliveradio.o wprogressbar.o bitmap.o dvbsubtitles.o tfeed.o vteletextview.o teletextdecodervbiebu.o teletxt/txtfont.o movieinfo.o seriesinfo.o wmovieview.o wseriesview.o tvmedia.o wtvmedia.o wpictureview.o main.o threadp.o  osdvector.o surfacevector.o osdopenvg.o ledraspberry.o mtdraspberry.o videoomx.o audioomx.o imageomx.o wjpegsimple.o remotelinux.o signal.o"

# All dynamic
# LIBSSTATIC=""
# LIBSDYNAMIC="-Wl,-Bdynamic -lpthread -lrt -lbrcmEGL -lbrcmOpenVG -lopenmaxil -lbcm_host -lavformat -lavcodec -lavutil -lavresample -ldl -lfontconfig -lfreetype -lMagick++-6.Q16"

# WIP
LIBSSTATIC="-Wl,-Bstatic -lfontconfig -lexpat -luuid -lfreetype -lpng -lavformat -lavresample -lavutil -lswresample -lz -lrt"
LIBSDYNAMIC="-Wl,-Bdynamic -lbrcmEGL -lbrcmOpenVG -lopenmaxil -lbcm_host -lpthread -lavcodec -lMagick++-6.Q16 -ldl"

g++ -Wall -o vompclient -L/opt/vc/lib -L/usr/lib/arm-linux-gnueabihf $BLOBS $OBJECTS $LIBSSTATIC $LIBSDYNAMIC


Hi,

I've fixed the errors for compiling on buster and it's in git. There are still several warnings that need looking into but at least it works now.

I've just tested compiling it against the latest libcec library package in Raspbian Stretch and it compiles OK. (I don't know if it actually works...) I think there has been a confusion in the repository with the package names and dependencies which appears to be resolved now if you start with installing libcec4-dev.

Just out of interest, assuming you use a web VDR manager, which one do you use?

Hi ralph, it's good to hear from someone still using vomp! Now if only the forum notify system had worked it wouldn't have taken me so long to read your message... Oops!

I have just tried to compile vompclient on a fresh Raspbian Stretch and yes, you're right it needs some attention. It is possible but really the downloads and documentation need updating to support it OOTB.

So, in answer to your questions:

1. How you describe is exactly how I use vomp - lircd with uinput events. Since I don't use that Pi's console for anything else, vomp is always hiding the login prompt with the strange characters so it's not really a problem. The strange characters are caused by the kernel's /dev/input system taking the characters that lircd-uevent gives it and handing it to the console as keyboard input. Since the remote buttons are never going to get past the login prompt it's an ignorable problem... Having said that I did once have a quick look into whether it is possible to have the kernel be selective about which input devices it uses for console keyboard input but I didn't find a way. Perhaps there is a way to "consume" the key press... Maybe a bit more digging around would find a way. I would rather not change to support lirc directly because the current system of using /dev/input enables lirc, USB IR receivers and real keyboards simultaneously.

2. As I said above, it is possible but with the following modifications to the instructions on the web site. The packages need to be altered like this:

Code Select Expand

sudo apt-get install libcec-dev libcec4=4.0.1+dfsg1-1+rpi1 libavresample-dev

This installs an old version of libcec. I still need to see if the later version works.

The git clone needs to be at HEAD, not "-b 0.5.0", as there are patches in there to enable compiling on stretch.

Also on my installation I need the following extra line in videoomx.cc

Code Select Expand

@@ -86,6 +86,8 @@ int VideoOMX::init(UCHAR tformat)
   if (initted) return 0;
   initted = 1;

+ bcm_host_init();


I was communicating with Marten Richter about this but I haven't done the fix properly yet. I think he recommended a better place for that line.

After all this, it compiles and works.

3. When I made the last release I tried rolling forward my VDR version as far as possible. I got to 2.2.0 which worked. 2.3.1 broke all four of my VDR plugins and was therefore a step too far. I will have to work on this.

4. Erm, good questions. We should write something on the VDR Wiki.

5. If I remember correctly it was Marten Richter who created the Debian integration. I'm sorry, I hadn't considered those files at all when I made the last release - I've not been near them. This needs work.

6. Yes! What do you want to tackle first?

7. Apparently not! I've always run vomp on single purpose Pis so it running as root hasn't been an issue. I had assumed that all the hardware access would require root permissions but it seems not. There is some code around VT switching that fails when not run as root but it doesn't seem to be making a difference. I will ask Marten what that does.


Having looked at all this in response to your message I think it's definitely time to re-base on Stretch and get a 0.5.1 released, and soon.

After the longest development delay yet.. VOMP 0.5.0 is finally finished!

New things:

• Improved EPG and recordings menu
• Poster, cast and banner picture through scraper2vdr support
• TV station logos
• Scrollable EPG texts
• Different skins (noOpacity inspired and two classic skins) - different color schemes
• TVBD inclusion through scraper2vdr
• Uses audio and subititle presets from VDR settings
• Mouse wheel support (Windows)
• High resolution vector based OSD (Windows)
• Support for Raspbian Jessie
• Experimental support for VDR 2.3.1/2
• Experimental new SD card image for Raspberry Pi

Fixes:

• Several crashes, lock-ups and memory leaks have been fixed
• Fixes for compatibility with newer Raspbery Pi firmware

Other notes:

The minimum VDR version is 1.7.35, the maximum is 2.2.0 but it may work with 2.3.1 and 2.3.2.

Raspberry Pi models 1 and 2 are known to work. If you run it on a 3 let us know how it goes.

The SD card download is a new and experimental feature. Please let me know of any problems, or even success stories!

The MVP is still supported for this release, but this is most likely the last version to support it.

The latest code does not compile for MVPs, meaning someone would have to work on it to bring it in-line with the new Raspberry Pi vomp code. Given this, the age of MVPs, the general move to HD, the low price of Raspberry Pis, the work involved in keeping two/three/many platforms in sync - how about we say thanks and goodbye to the great Hauppauge MediaMVP, leaving the last working version at 0.4.1, with server 0.4.1?

Feel free to vote and comment!

I bought a Cubietruck. I had the same idea - could vomp run on it... However, given that it is such a major PITA to get _anything at all_ working on a Cubietruck, getting vomp to run on it could be an entire lifetime's work.

Having said that, it probably has all the required bits and pieces. If someone would like a challenge ... !

New:

• Gradients in menus - nicer look
• Shutdown-VDR patch from Yaris included
• Resume as default action from dingo35
• Compatibility with VDR 1.7.36 to 2.1.1

Bug fixes:

Many bugs fixed and improvements mainly to the Raspberry Pi port by Marten Richter. There are fixes in:

• Audio downmixing
• Stream & demuxing handling
• CEC
• MCE remote controls
• Channel list on MPEG2 only devices
• Typing a channel number in the radio list
• Some fixes for Windows 8
• ... and many more. Thanks Marten!

Hi,
It's nothing really to do with vomp and won't be replacing any part of vomp.

At the moment it's a personal project that I'm just playing with. The server side is so generic though that I put it on the public git web site just in case anyone wanted to use it for something.

Hi Hans,

I have applied the first patch (thanks) but not the second because of Marten's comments.

Also, pressing back with no summary showing should return you to the recordings list - this is by design and is how I use it, or am I misunderstanding something?

Thanks,

Chris