News:

Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - stu-e

#31
VOMP General / MVP / Re: OT: VOMP HD Device
October 15, 2009, 10:18:00
Thanks for bringing this to everybody's attention. I was not aware of it.

Googling 'wdtv hack' gives lots of results. It looks like there is already a well established modding community for this device.

These sites give a good overview of what has been achieved:
http://www.wdtvc.com/2009/04/02/wdlxtv-04-enhanced-wdtv-firmware
http://b-rad.cc/wdlxtv
http://wiki.wdtv.org/doku.php

It appears similar to the mvp if only in the respect that the Linux kernel is accessible but the video+audio output is closed source.

Just how feasible would it be to port Vompclient to this platform?

BTW the media device is a Sigma SMP8635LF

Stu-e

[Edit] There appears to be 2 different models. Anybody know the difference between them?:
WDAVP00BE (Amazon £70)
WDBAAP0000NBK-EESN (Amazon £105)
#32
Thanks.
#33
VOMP General / MVP / Vomp source documentation
July 28, 2009, 13:55:20
Can anyone give any hints on how a novice coder like me could begin to understand how vompserver works?
I pushed the vompserver source code through doxygen but it does not help much.

In addition is the communications protocol documented anywhere?

Thanks
Stuart
#34
VOMP General / MVP / Re: vomp and vdr >1.7.3
May 27, 2009, 23:20:45
I got it working after simply renaming Make.config.template to Make.config in the vdr source directory.
This was suggested by Thomas Gunther on the vdr mailing list. He quoted a bit of vdr history that perhaps the Vompserver plugin's authors should take note of:

From HISTORY of VDR-1.7.4:
- Added "DEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE"
  to Make.config.template (thanks to Johann Friedrichs for pointing this out).
  Plugin authors should add this line to their Makefile or Make.config if they use
  file access functions that need special versions for 64 bit offsets.

I'm really grateful for the work you put in getting support for >vdr-1.7.3.

Many thanks
#35
VOMP General / MVP / Re: vomp and vdr >1.7.3
May 26, 2009, 21:33:33
Same error with vdr-1.7.5:
vdr: ./PLUGINS/lib/libvdr-vompserver.so.1.7.5: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi

Stu-e
#36
VOMP General / MVP / Re: vomp and vdr >1.7.3
May 26, 2009, 20:41:29
The symbol error actually occurred when I ran vdr:
vdr: ./PLUGINS/lib/libvdr-vompserver.so.1.7.7: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi

I tried a fresh cvs download, applied newserverpatch2.patch and got the same error.
make clean-plugins;make plugins did not help either.

The vompserver lib is in the PLUGINS/lib directory as it says in the error message.

Googling the symbol gives reports of the same error with streamdev plugin, but I was not able to get any more detail than that.

I'm using gcc 4.3.2 and an unpatched vdr 1.7.7

Stu-e
#37
VOMP General / MVP / Re: vomp and vdr >1.7.3
May 26, 2009, 11:55:50
Do these patches apply to current cvs because I'm getting an undefined symbol error when I come to make plugins in my vdr source directory?

Just a wild stab but has it got anything to do with bool ResumeIDLock? Comparing newserverpatch2 patch with the Yaris 07_rec_resume_vdr patch, this bool is declared as extern in vompclientrrproc.h and declared again in vompclientrrproc.c, yet in Yaris it is declared as static in vompclientrrproc.h only.

My C coding skills aren't that strong. Please could anyone comment on this?

Stu-e
#38
VOMP General / MVP / Re: Failed IR remote
August 08, 2008, 09:20:27
This is indeed strange!

When my old style remote went wrong, Lirc irrecord reported completely different remote codes compared to when the remote was originally working.
When the remote magically 'fixed' itself, irrecord reported the original codes again!

Since the remote first failed I bought a new style remote and I have been using that ever since. I only noticed the old remote started working again after I started using it with vdr and lirc.

Stuart
#39
VOMP General / MVP / Re: Vomp media player
May 29, 2008, 23:51:55
I just tried to play some mp3s encoded using the LAME nogap feature for gapless playback.
There is still a gap between tracks that would normally have no gap between them.
The tracks however play gapless using Xine.

Any chance Vomp Media Player can support gapless mp3 playback?
#40
VOMP General / MVP / Re: Vomp for PCH
May 21, 2008, 13:50:05
Here's hoping they release at least the GPL'd parts of the PCH firmware sourcecode
http://www.networkedmediatank.com/viewtopic.php?t=4145&sid=a94b39732a8ffa8712988e92d124b533

Surely that would greatly accelerate user app development on the PCH.
#41
VOMP General / MVP / Vomp for PCH
May 21, 2008, 09:39:45
Is anybody else following what is going on here?
http://www.networkedmediatank.com/viewtopic.php?t=2190

*Scratches chin and ponders "VompHD"*
#42
VOMP General / MVP / Re: Vomp media player
May 01, 2008, 09:39:00
Yes gcc 4.2 compiles ok using const char* instead of the casts.

Thanks
Stuart
#43
VOMP General / MVP / Re: Vomp media player
April 30, 2008, 09:36:06
Gcc 4.2

I'll try const instead of the cast and let you know if it compiles ok or not.

Stuart
#44
VOMP General / MVP / Re: Vomp media player
April 26, 2008, 01:37:27
Hi Andreas
I get an error when building vompserver with your latest media patches:
cc1plus: warnings being treated as errors
medialauncher.c:75: warning: deprecated conversion from string constant to 'char*'
medialauncher.c:75: warning: deprecated conversion from string constant to 'char*'
medialauncher.c:75: warning: deprecated conversion from string constant to 'char*'
medialauncher.c:75: warning: deprecated conversion from string constant to 'char*'
make[1]: *** [medialauncher.o] Error 1

I edited the assignment to mediatypes as follows:
static struct {
  char* mtypename;
  ULONG mtypeid;
} mediatypes[]= {
  {(char *) "PICTURE",MEDIA_TYPE_PICTURE},
  {(char *) "AUDIO",MEDIA_TYPE_AUDIO},
  {(char *) "VIDEO",MEDIA_TYPE_VIDEO},
  {(char *) "LIST",MEDIA_TYPE_DIR}
};

Now it builds without error.

Stuart
#45
Does this mean there is a future for Vomp with high definition video, albeit without the Hauppauge MediaMVP hardware? I much prefer the Vomp frontend to VDR's own OSD, but with the transition to high def I was resigned to giving up Vomp at sometime in the near future.

You might want to consider at an early stage what impact any development might have upon maintaining a front end system that can boot quickly from either a cold or standby state.

Good luck!