Topics

Although just one day experience, I really like the scraper_support version; it seems more stable than the current vomp-client version (I think that's because of the segfault conditions Marten debugged); haven't had to reboot once yet...(knock on wood).

I just have two small bugs to report:
1) When displaying a 16:9 screen on 4:3 TV in letterbox mode, the lower black bar is not black but dark blue; the upper black bar is black, as expected.
2) When exiting a recording, and resuming it, the recording starts about 30 seconds later than where it was exited. This is not new behaviour, it also happened on the current (git master) vomp-client.
I guess this has something to do with either the vomp-server or the vomp-client starting at the first i-frame it encounters, but it means all p- and b-frames in between the exiting and the resuming are lost.

IMHO, the correct thing to do would be to jump back to the first I frame and start playing from there; this is the behaviour VDR itself does. It usally means the resume point is a little before the exiting point, but a little "replay" of a recording is less annoying than missing half a minute of the story 
I have no idea how complex that might be, a quick (but less elegant) fix would be just to rewind 30 seconds after resuming.

Marten, any ideas on this?

Hi all,

Always when I am going to play with vompclient I keep forgetting which command line parameters I need to get the logging on screen. The "usage" message when doing vompclient -h does not help me, so here is a patch to improve the help message:

diff -Naur vompclient.old/main.cc vompclient.new/main.cc
--- vompclient.old/main.cc  2014-11-17 10:26:07.352924435 +0100
+++ vompclient.new/main.cc  2014-10-15 12:57:19.607563854 +0200
@@ -129,7 +129,7 @@
   char* setServer = NULL;
   int c;

-  while ((c = getopt(argc, argv, "cdns:")) != -1)
+  while ((c = getopt(argc, argv, "cdhns:")) != -1)
   {
     switch (c)
     {
@@ -144,11 +144,15 @@
       case 's':
         setServer = optarg;
         break;
-      case '?':
-        printf("Unknown option\n");
-        return 1;
+      case 'h':
       default:
-        printf("Option error\n");
+        printf("Usage: vompclient [options]\n");
+       printf("Options:\n");
+       printf("  -c        set 'crashed' variable\n");
+       printf("  -d        show debug messages on standard output; implies -n\n");
+       printf("  -n        do NOT daemonize into background\n");
+       printf("  -s server set 'setServer' variable to server\n");
+       printf("  -h        show this help message\n");
         return 1;
     }
   }


Perhaps someone (Marten?) can improve on the -c and -s message, I really can't figure out what this is doing!

Marten, could you put this into git? Thanks!

Hi all,

When compiling GIT version of vompclient on Raspi (which is current on Raspbian) first I have to install a new package to fullfill a new dependency:
apt-get install libavresample-dev   (documenting this for others).

But then I come in to this error:
audioomx.cc: In member function 'unsigned int AudioOMX::AdvanceMpAudioSync(const UCHAR*, unsigned int, unsigned int*)':
audioomx.cc:1579:15: warning: declaration of 'test' shadows a member of 'this' [-Wshadow]
audioomx.cc: In member function 'unsigned int AudioOMX::AdvanceAc3AudioSync(const UCHAR*, unsigned int, unsigned int*)':
audioomx.cc:1659:15: warning: declaration of 'test' shadows a member of 'this' [-Wshadow]
audioomx.cc: In member function 'unsigned int AudioOMX::AdvanceAacLatmAudioSync(const UCHAR*, unsigned int, unsigned int*)':
audioomx.cc:1679:15: warning: declaration of 'test' shadows a member of 'this' [-Wshadow]
audioomx.cc: In member function 'void AudioOMX::getDownMixMatrix(long long unsigned int, int*, int*)':
audioomx.cc:1710:18: error: 'AV_CH_BACK_LEFT' was not declared in this scope
audioomx.cc:1710:36: error: 'AV_CH_SIDE_LEFT' was not declared in this scope
audioomx.cc: In member function 'UINT AudioOMX::DeliverMediaPacket(MediaPacket, const UCHAR*, UINT*)':


I tried fiddling around:

-adding a "#include <libavutil/channel_layout.h>" to audioomx.h
then new errors occur, solving them:
-adding -fpermissive flag to CXXFLAGS_DEV in GNUMakefile
-adding -ldl and -lfontconfig to LIBS in GNUMakefile

..then it compiles but audio is some kind of "Donald Duck" like sound.

What am I doing wrong?

The subject says it all : 4:3 content shown in letterbox on 4:3 TV.

Settings are 4:3 TV  and letterbox.

Hi all,

Great work on the vompclient on Raspberry, have started to use it and enjoying it a lot! The default vompclient branch from git has some annoying bugs in it (e.g. hanging when fastforwarding/jumping through recordings too quickly), but luckily these seem to be solved in the vompclient-marten branch.

One small bug I spotted: when my vompclient has its audio Muted, and I start playing a recording, sound is audible. Pressing the mute button twice (unmute first time, mute again second time) works fine. Same thing on live tv. I should mention I tap my audio through the 3.5 mm plug, not using HDMI.

Seems like just a small initialization error, any idea on where to solve this?

Thanks!

Attached a patch to have the green on board led working as an on/off indicator for vompclient.

The other leds (except for the red power led) can be cleared by this patch (but the kernel needs to be recompiled for that):
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=31&t=12530&sid=f152b5af6d3915a18ed8b2d005daa801&start=25

Hi all (but especially Marten and Christophe),

As I was remapping the keys of my MCE remote I noticed that most of the keys worked right out of the box, but a few just didn't work because of conflicting naming schemes between linux-kernel and vompclient.
Now I suspect vompclient was earlier with these names than the kernel, and I also suspect the kernel-developers are/cannot be aware of a nice application like VOMP.

Perhaps it would be a good idea to change

Code Select Expand

KEY_FORWARD to KEY_FASTFORWARD
KEY_BACK to KEY_REWIND
KEY_BACKSPACE to KEY_EXIT
in remotelinux.cc .

It would make sure that these keys work right out of the box on all MCE compliant remotes on these keycodes, and (AFAIK) would not break any other remotes (Marten, Christophe, can you confirm this?)

Arguable would be these keys:

Code Select Expand

KEY_POWER to KEY_SLEEP
KEY_M to KEY_MEDIA
..since I have nu clue on how other remotes name these keys. It makes more sense to my to name the power key KEY_POWER then KEY_SLEEP, but I am not sure how dominant Microsofts market position to other suppliers is on this small issue.
Also, the menu key on the hauppauge remote is also labeled I(nfo), and it is used as a KEY_INFO button in live TV in vomp, but kind of as a KEY_MEDIA when playing recordings.

What do you guys think?

Best regards ALL !!!

Finally got my Raspberry Pi, installed vompclient and then discovered some keys of my Microsoft MCE remote control were not recognized. Especially the BACK key (marked BACK/EXIT on hauppauge's remote) is a pain when missed.
Also this remote lacks the red/green/yellow/blue keys, but it has four unused keys in a row (Recorded TV, Guide,Live TV and DVD Menu) which can be remapped to those colours easily.

Also Power, Menu, Fast forward and Rewind keys were not working.

Now first thing I did was

Code Select Expand

apt-get purge inputlirc
apt-get purge lirc
apt-get autoremove

to get rid of all LIRC stuff. LIRC has had its use in the far past when people bought an IR-sensitive transistor and hooked it up to their serial RS232 port. In this day and age of USB and event- and input driven code in the kernel you don't need it, it will only mess up stuff.

Then test if your remote is recognized by the kernel:

Code Select Expand

ir-keytable -t

Now press keys on your remote, and if your remote is recognized by the kernel it reports every keypress. Now press all the keys you want to remap, and write down their key-codes. E.g. I want to remap my DVD-Menu key to act like the blue button on my old hauppauge remote, pressing that key reports: KEY_DVD.

Now look at by which driver, and at which table it is recognized:

Code Select Expand


root@raspvideo:/tmp# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event0) with:
        Driver mceusb, table rc-rc6-mce
        Supported protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC other
        Enabled protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC other
        Repeat delay = 500 ms, repeat period = 125 ms



Now generate new keymap file:

Code Select Expand

ir-keytable --read --device=/dev/input/event0 >/etc/rc_keymaps/rc6_mce

Now change the lines of the keys you want to remap (note how we remap the KEY_DVD to KEY_BLUE):

Code Select Expand


scancode 0x800f040c = KEY_POWER #was KEY_SLEEP (0x8e)
scancode 0x800f040d = KEY_M #was KEY_MEDIA (0xe2)
scancode 0x800f0414 = KEY_FORWARD # was KEY_FASTFORWARD (0xd0)
scancode 0x800f0415 = KEY_BACK #was KEY_REWIND (0xa8)
scancode 0x800f0423 = KEY_BACKSPACE #was KEY_EXIT (0xae)
scancode 0x800f0424 = KEY_BLUE #was KEY_DVD (0x185)
scancode 0x800f0425 = KEY_YELLOW #was KEY_TUNER (0x182)
scancode 0x800f0426 = KEY_GREEN #was KEY_EPG (0x16d)
scancode 0x800f0448 = KEY_RED #was KEY_PVR (0x16e)

The left-hand keynames are the ones that VOMP expects, you can find them in the source code of vompclient in remotelinux.cc .

Now test the keymap by writing it:

Code Select Expand

ir-keytable --write=/etc/rc_keymaps/rc6_mce --device=/dev/input/event0

Your vompclient should now use new mappings, but will lose these mappings after reboot.

Code Select Expand

vi /etc/rc_maps.cfg
change line:

Code Select Expand

*  rc-rc6-mce               /lib/udev/rc_keymaps/rc6_mce
to:

Code Select Expand

#*  rc-rc6-mce               /lib/udev/rc_keymaps/rc6_mce
#remap microsoft MCE remote color buttons for VOMP
* rc-rc6-mce               rc6_mce

Now you would expect that linux would load this settings at reboot, but it doesn't at my machine. I suspect it is because the kernel at Raspbian is compiled without CONFIG_RC_MAP set, but I am not sure about that.

What I am sure about is that it will load when specified explicitly, add these lines at the end of /etc/rc.local, just before the exit statement:

Code Select Expand

ir-keytable -a /etc/rc_maps.cfg
/usr/local/bin/vompclient

Have fun!

Hello all,

First of all big thanks to Chris and Marten for the new vomp 4.0; working great here!

I made some patches which I think are improvements:

• resume_as_default.diff  makes the "Resume" button as default, instead of the "Play" button. For recordings that are viewed for the first time, the behaviour remains the same, for recordings that are viewed before this is usually the wanted behaviour. It also reduces the number of button presses because moving to "Move" or "Delete" takes less keypresses.
  I also did some code optimizations which reduce the number of lines and (IMHO) code readability significantly; it also reduces object code by 4K.
  
• jump-10s-5min.diff makes use of the fact that up, down, left and right keys are having functions that are already available through other buttons on the remote (like play, pause, rewind and fastforward). This patch remaps the keys to:
  
  
  • UP: Forward 10s
  • DOWN: Back 10s
  • RIGHT: Forward 5 min
  • LEFT: Back 5 min/li]
    
  It also solves a small bug which happens when pressing BACK during a recording and no summary is being shown.
  

I hope you like this patches and Chris, would you please consider applying these patches to the repository?

Thanks!

Hi all,

I noticed that fast forwarding with 16x and 32x speed did not work anymore. Also I noticed that default button in the recordings menu is "Play"; although this might seem logical, IMHO "Resume" is a better default button, since
a) when a recording is unwatched it does the same as Play
b) when a recording is watched, it resumes at the last point, which with normal usage will be the desired behaviour.

I attach the two patches (Chris, can you put these in CVS?) and a compiled binary with the patches included.

EDIT: that's ashame, maximum attachement size is 2000K and the dongle is 2039K ... can someone lift this limit since dongle size is this big for years now....

Trying to solve some problems in the dongle software, I stumbled upon the problem that makedevenv-6 does not work on debian squeeze. When compiling the kernel this error occurs:

Code Select Expand

scripts/Configure: line 549: .: .config: file not found
scripts/Configure: line 551: .: .config-is-not.14056: file not found

Googling revealed other people have same problem, but no solution found. The problem seems to be that the bash dot/source command fails to look in the current directory in bash4, which it did correctly in bash3.

I solved this by creating a patch; to have this patch activated at the right time, I had to adapt the "patch" script; it is now adapted in such a way that future patches can be added without changing the script.

Perhaps Chris or Marten could add the patch and the changed patch script to kernel-1.tar.gz, in that case the makedevenv-7 script can be replaced by the makedevenv-6 script, since no other changes were made.

I have come across two different bugs in vompserver:
1) sometimes, when I start a recording, the current time/total time is not filled in correctly, but displays  --/-- .
When it goes wrong, the client sends command 7 directly after selecting the recording:

Code Select Expand

09:47:21.133495 [debug]  RecPlayer - FILENAME: /media/video0/NED2/2010-02-03.14.57.2-0.rec/00001.ts
09:47:21.133561 [debug]  RecPlayer - File 1 found, totalLength now 130461284, numFrames = 6599
09:47:21.133599 [debug]  RecPlayer - FILENAME: /media/video0/NED2/2010-02-03.14.57.2-0.rec/00002.ts
09:47:21.133686 [debug]  RRProc - written totalLength
09:47:21.133725 [debug]  RRProc - threadMethod waiting
09:47:21.134574 [debug]  Client - Received chan=1, ser=9808, op=7, edl=12
09:47:21.134611 [debug]  RRProc - recvReq set req and signalled
09:47:21.134632 [debug]  Client - Waiting
09:47:21.134657 [debug]  RRProc - thread woken with req, queue size: 1
09:47:21.134677 [debug]  RRProc - thread while
09:47:21.134702 [debug]  RRProc - received command 7
09:47:21.134723 [debug]  RRProc - getblock pos = 0 length = 10000


And when it goes right, it first does command 16:

Code Select Expand

09:47:21.453342 [debug]  RecPlayer - FILENAME: /media/video0/NED2/2010-02-03.14.57.2-0.rec/00001.ts
09:47:21.453409 [debug]  RecPlayer - File 1 found, totalLength now 130461284, numFrames = 6599
09:47:21.453448 [debug]  RecPlayer - FILENAME: /media/video0/NED2/2010-02-03.14.57.2-0.rec/00002.ts
09:47:21.453532 [debug]  RRProc - written totalLength
09:47:21.453572 [debug]  RRProc - threadMethod waiting
09:47:21.460124 [debug]  Client - Received chan=1, ser=9814, op=16, edl=4
09:47:21.460168 [debug]  RRProc - recvReq set req and signalled
09:47:21.460189 [debug]  Client - Waiting
09:47:21.460216 [debug]  RRProc - thread woken with req, queue size: 1
09:47:21.460237 [debug]  RRProc - thread while
09:47:21.460261 [debug]  RRProc - received command 16
09:47:21.460300 [debug]  RRProc - Wrote posFromFrameNum reply to client


2) ONLY on recordings from transponder 12515H on S19.2E (Ned1, Ned2, Ned3), there are positioning problems.
-When you are looking to a recording, the "seconds" field updates much to slow (so it takes 1,5 seconds to show 0.01)
-When fastforward or rewind, the point from which is jump is "back in time". Here is the log when I jump forward 10 seconds:

Code Select Expand

10:00:35.091598 [debug]  RRProc - received command 7
10:00:35.091621 [debug]  RRProc - getblock pos = 17550000 length = 100000
10:00:35.091928 [debug]  RRProc - written 100000
10:00:35.174426 [debug]  RRProc - Finished getblock, have sent 100012
10:00:35.174549 [debug]  RRProc - threadMethod waiting
10:00:35.256136 [debug]  Client - Received chan=1, ser=10804, op=16, edl=4
10:00:35.256265 [debug]  RRProc - recvReq set req and signalled
10:00:35.256289 [debug]  Client - Waiting
10:00:35.256321 [debug]  RRProc - thread woken with req, queue size: 1
10:00:35.256344 [debug]  RRProc - thread while
10:00:35.256371 [debug]  RRProc - received command 16
10:00:35.256431 [debug]  RRProc - Wrote posFromFrameNum reply to client: position=10600756 framenumber=485
10:00:35.256464 [debug]  RRProc - threadMethod waiting
10:00:35.257444 [debug]  Client - Received chan=1, ser=10805, op=7, edl=12
10:00:35.257478 [debug]  RRProc - recvReq set req and signalled
10:00:35.257498 [debug]  Client - Waiting
10:00:35.257522 [debug]  RRProc - thread woken with req, queue size: 1
10:00:35.257542 [debug]  RRProc - thread while
10:00:35.257562 [debug]  RRProc - received command 7
10:00:35.257631 [debug]  RRProc - getblock pos = 10600756 length = 100000


These particular stream are OK when live viewing, and also in VDR itself. I noticed that the "resume" function works correctly, so it has to do with the way vompclientrrproc.c derives the framenumber from the stream through ntohl. I cannot detect where this req->data is filled, though ...

A temporary fix is in line 1222 of vompclientrrproc.c:

Code Select Expand

  //ULONG frameNumber = ntohl(*(ULONG*)req->data); //FIXME DINGO
  frameNumber = x.recplayer->frameNumberFromPosition(x.recplayer->getLastPosition());

..but this isnt really ok since the last position is only a rough estimate, and is not updated frequently.

Can someone (Marten?) point me into the right direction: which fields in the ts-stream are causing this problem, and/or where is this req->data filled, and/or how to solve this in vomp (if VDR is not the right place to solve this) ?

Thanks Dingo.

I have made a small diff to add pin-protection to VOMP. It closely works together with the widely used vdr-pin-plugin; which this plugin you can protect recordings, channels, menu-items and plugins with a pin-code.

The modification I post (made to current cvs) makes Vomp aware of the protection of recordings and channels, and by default does not show them on your clients.

Only on a client that has a line:

Code Select Expand

[General]
ShowPinProtected = 1


in it's vomp-MAC.conf will show the protected channels and recordings.

It is tested on vomp-0.3.1, cvs, and both windows-clients and mvp-clients. It is also works properly together with the more basic "Childlock" patch, which is added in Yaris versions.

Please add this patch to CVS, so anyone can profit from it. It is only small code with relatively small impact, but is important to all parents among us. In order not to disturb the functioning of non-pin-plugin users, the patches should be placed between #ifdef USE_PINPLUGIN  and #endif statements.

PS: Somehow this post does not show at the top when one sorts on "last post"...?

Hi all!

I'm trying to build some new functionality in vompclient. For that, I have pulled current cvs client version, and imported it in my Visual C++ Express 8 environment. It all compiles fine, and it runs great too: live tv, recordings, all seems to be ok.

BUT when choosing "Timers" from the main menu, the applications crashes and wants to send a report to Microsoft.

When run from the debugger, it says:

Code Select Expand


Program: <path>vompclient.exe
File: f:\dd\vctools\crt_bld\selfx_86\crt\src\strftime.c

Line: 402

Expression: timeptr != NULL



The error seems to be in one of the libraries used, not in vompclient itself.

When I run the vompclient for windows from the loggytronic home page, all works fine.

Anybody any idea how I can solve this?

Marten,

Suppose I would like to enhance Vomp for Windows in such a way that it could replay vdr h.264 ts-files, would it be possible to have it use the CoreAVC decoder? Would it be simply reconnecting the CoreAVC decoder with graphedit?

I understand things would have to be done in the (re-)muxing area, it's the graphical part of windows I'm not familiar with...

Hi all,

I am a very happy user of vomp-0.3.0-1.Yaris and vomp-dongle-0.3.0-3-Yaris. Since version 0.3.0, my VDR server does not always shut down automatically; it seems that sometimes the vomp server keeps on generating events, so that the event-timeout that should shut VDR down never happens.

When I try to shutdown VDR manually, it reports: vomp client(s) connected - shutdown anyway?  ; at that moment no vomp-clients are active (that is; switched off). Manual shutdown goes ok, and resets the situation: from that moment on VDR will shutdown after event-time-out , but after a few days / weeks the problem arises again.

Anyone recognise this problem? I did not have this with vomp-0.2.6 ; on my network I have 3 hauppauge MVP clients, and also 2 windows vomp clients... Not sure whether this is a vomp problem or a Yaris-version problem...

Thanks in advance!

Hi all,

In trying to debug my bootp/tftp problems, I noticed that when I am using  -P 'vompserver -c /usr/local/vdr/etc/plugins' to avoid the "ERROR: plugin '<no name given>' called cPlugin::ConfigDirectory(), which is not thread safe!" message, my syslog says:

Feb 14 11:53:44 videoserver2 vdr: [17826] VOMP: Config file found
Feb 14 11:53:44 videoserver2 vdr: [17826] VOMP: Logging disabled

even when logging is specified in vomp.conf (which seems to be found).

When using -P vompserver logging behaves as expected.

Problem is in mvpserver.c, when logging is supposed to start:
char* cfgLogFilename = config.getValueString("General", "Log file");

cfgLogFilename always gets a NULL value.

I tried to debug this problem, but got stuck because dsyslog is not working in config.c ; all errors are supposed to get logged in the log file, but hey, nothing gets logged because vompserver thinks logging is disabled.

I'm using vompserver-0.2.7 , not sure whether -c is supposed to work already in this version, but it seems to be "half implemented".

Any other way I can get read if this "ERROR: plugin '<no name given>' called cPlugin::ConfigDirectory(), which is not thread safe!" message?

Could it be causing my problem that Tftpd is never kicking in?

Hi all,

I'm using vomp for several years now, and I am very happy with it. One thing bugs me, and that is that I've never succeeded in using the built in bootp/tftp functionality. Now that I am going to use a new router without tftp functionality, I want to give it another try.

Having modified vomp.conf and vomp-xx-xx.conf according to the instructions, my vomp-logfile reports:

14:34:13.694852 [info]   Main - Logging started
14:34:13.695080 [debug]  UDPReplier - UDP replier started
14:34:13.695205 [debug]  BOOTPD - Starting bootpd
14:34:13.695281 [debug]  BOOTPD - Starting wait
14:34:13.695314 [debug]  BOOTPD - Bootp replier started
14:34:13.695389 [info]   Main - TFTP path '/var/lib/tftpboot/'
14:34:13.695413 [debug]  Tftpd - Starting TFTPd
14:34:13.695480 [debug]  Tftpd - Starting wait
14:34:13.695511 [debug]  Tftpd - TFTP server started with base path '/var/lib/tftpboot/'
14:34:13.695585 [debug]  MVPRelay - MVPRelay replier started
14:34:13.695612 [info]   Main - MVPRelay started
14:34:13.695763 [debug]  Main - MVPServer run success
14:36:35.935878 [debug]  BOOTPD - Wait finished
14:36:35.936003 [debug]  BOOTPD - Got request
14:36:35.936424 [debug]  Config - Opened config file: /usr/local/vdr/etc/plugins/vomp-00-0D-FE-00-3F-92.conf
14:36:35.936452 [debug]  BOOTPD - Opened config file: /usr/local/vdr/etc/plugins/vomp-00-0D-FE-00-3F-92.conf
14:36:35.936550 [debug]  BOOTPD - Found IP 10.0.0.120 for MVP
14:36:35.936628 [debug]  BOOTPD - Will enforce IP 10.0.0.120 on MVP even if it already has another
14:36:35.936655 [debug]  BOOTPD - Giving MVP IP from config
14:36:35.936900 [debug]  BOOTPD - Starting wait
14:36:44.955845 [debug]  BOOTPD - Wait finished
14:36:44.955936 [debug]  BOOTPD - Got request
14:36:44.956207 [debug]  Config - Opened config file: /usr/local/vdr/etc/plugins/vomp-00-0D-FE-00-3F-92.conf
14:36:44.956236 [debug]  BOOTPD - Opened config file: /usr/local/vdr/etc/plugins/vomp-00-0D-FE-00-3F-92.conf
14:36:44.956343 [debug]  BOOTPD - Found IP 10.0.0.120 for MVP

and so on...

I turned my dhcp server and my xinetd (with tftpd) off, and used manual IP override by vomp, but it seems that Tftpd and Tftpclient do not kick in. There is also nothing listening on port 69, where usually tftp listens.

I read somewhere that vdr needs to run as root to access ports <1027 . Do I need to run vdr as root to have vompserver listen to port 69, or is there some other problem?  Any suggestions on solving/debugging this problem?

Thanks in advance!

P.S.: Running vdr as root is not an option on my production platform, so that's why I didn't try running as root myself....

Hi all,

I am enjoying the new 0.2.7-3 windows version of vompclient, but I noticed on my new 16:9 screen that the aspect ratio seems to be fixed to 4:3 , even when having chosen 16:9 in the settings menu.

When watching 16:9 streams, this leads to "tall people" on TV, because the picture is stretched vertically to fit into the 4:3 window.

This problem arises both in windowed as in full screen mode.

I use MPV and MPA video codecs.

Am I the only one experiencing this? How can I get the 16:9 streams correctly on my 16:9 screen?

Thanks!

PS: Just found out that vompclient reacts as I would expect when choosing the settings: TV aspect ratio 4:3 , letterbox. Is it me that I don't understand the settings, or are 16:9 and 4:3 switches reversed?

Hi,

First of all thanks for this great client! Now I don't even need media-mvp boxes anymore on the places where a computer is present!

Just wanted to make one small remark: shortly after the release of vomp 0.2.5 (not the windows version) I added some translations and corrections. vomp 0.2.6 carried the changes, but vomp 0.2.6 for windows did not...
Could someone please add "current" language-data files to the windows-environment?

Thanks!