[mythtv] issues with Windows NUV decode

[Lawrence Rust]

On Thu, 2011-04-14 at 22:28 +0100, jonathanjstevens at gmail.com wrote:
> Hi,
> 
> 
> Hope this is OK coming to the dev list.
> 
> 
> I've recently rebuilt my MythTV systems to 0.24 fixes. All the backend
> work lovely, but I'm having a few challenges with some of the
> frontends which are Windows.
> I've chosen to cross-compile, I am compiling on a XEN VM (paravirt
> F14) using mingw32 and the script as
> per http://www.softsystem.co.uk/mythtv/index.htm
> 
> 
> Compilation appears to work OK (at first glance).
> 
> 
> Installer works, and MythTV successfully installs on the Windows box
> (XP and Win7).
> 
> 
> Live TV works, open GL and DirectX - I assume native MPEG from the DVB
> cards.
> However, when I try to watch recorded TV I get an error saying that
> the frontend can't start the NUV decoder - it doesn't appear to be in
> the av libs.

Could you post the log output from mythfrontend leading up to the
problem?

Question - if you're recording DVB input then the recordings should be
in mpg format.  Where did the Nuppel recordings come from?

> So, I started looking at the compile a bit more and found these....
> 
> 
> Installing mythtv (release)
> *********************************************************************
> 
> 
> make install...
> INSTALL libavformat/libmythavformat.dll
> STRIP install-libavformat-shared
> install: cannot stat `libavformat/libmythavformat-52.lib': No such
> file or directory

The .lib files are not used by the mingw32 cross tools so this can be
ignored.

[snip]

> which makes me think perhaps some of the libraries are not compiling
> into the dlls properly?

It's just that the ffmpeg make script wants to make lib files for VS and
other Windows linkers.  Mingw uses the dll.a files.

> So, a bit more digging into the compile and I find...
> 
> 
> Creating library file: libavutil/liblibmythavutil.dll.a
>
lib.exe /machine:i386 /def:libavutil/libmythavutil-50.def /out:libavutil/libmythavutil-50.lib
> make[1]: lib.exe: Command not found
> make[1]: [libavutil/libmythavutil-50.dll] Error 127 (ignored)
> LD libavcore/libmythavcore-0.dll
> Creating library file: libavcore/liblibmythavcore.dll.a
>
lib.exe /machine:i386 /def:libavcore/libmythavcore-0.def /out:libavcore/libmythavcore-0.lib
> make[1]: lib.exe: Command not found
> make[1]: [libavcore/libmythavcore-0.dll] Error 127 (ignored)

Again this can be ignored since the .lib files are not used.

[snip]
> 
> Which seems to explain why the libraries are not being created?
> 
> 
> lib.exe appears to be a Windows exe, not a mingw32 on Linux tool - so
> I'm a little puzzled as to how this is getting into the scripts...
> So anyway, this appears to being created by the configure script in
> FFmpeg...

Agreed, ffmpeg believes it's building a Windows installation, that is
intentional, and so wants to build .lib files.  The configure script
should be fixed to not do that.  However, I've had a devil of a job
getting just a few essential changes committed.  Consequently I've gone
for the easy path and lived with the warnings.

> [user at compiler FFmpeg]# more config.mak 
> ifndef FFMPEG_CONFIG_MAK
> FFMPEG_CONFIG_MAK=1
> SHFLAGS=-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
> -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a) -Wl,--ena
> ble-runtime-pseudo-reloc -Wl,--enable-auto-image-base
> -Wl,--version-script,$(SUBDIR)lib$(NAME).ver
> LIB_INSTALL_EXTRA_CMD=$$(RANLIB) "$(LIBDIR)/$(LIBNAME)"
> SLIB_CREATE_DEF_CMD=
> SLIB_EXTRA_CMD=-lib.exe /machine:$(LIBTARGET) /def:$$(@:
> $(SLIBSUF)=.def) /out:$(SUBDIR)$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.lib)
> 
> 
> Now I can see why this would be generated by FFmpeg itself, but a bit
> more digging further up the tree...
> 
> 
> [root at compiler mythtv]# grep lib.exe *
> configure:        SLIB_EXTRA_CMD='-lib.exe /machine:$(LIBTARGET) /def:
> $$(@:$(SLIBSUF)=.def) /out:$(SUBDIR)$(SLIBNAME_WITH_MAJOR:
> $(SLIBSUF)=.lib)'
> [root at compiler mythtv]# 
> 
> 
> OK, so "lib.exe" is being inserted by the main MythTV configuration
> script, see below for the config.log

Yes, this should be removed from configure if cross compiling.  Send a
patch to Trac.

> [root at compiler mythtv]# more config.log
> Thu Apr 14 21:48:04 BST 2011
>    ./configure --prefix=/windows/mythtv/build/mythinstall
> --runprefix=.
>
--qmake=/windows/mythtv/build/mythbuild/qt-everywhere-opensource-src-4.7.0/bin/qmake --enable-cross-compile --cross-prefix=i686-pc-mingw32- --target_os=mingw32 --arch=x86 --sysinclude=/windows/mythtv/build/mythinstall/include --extra-cflags=-I/windows/mythtv/build/mythinstall/include --extra-cxxflags=-I/windows/mythtv/build/mythinstall/include --extra-libs=-L/windows/mythtv/build/mythinstall/lib --disable-avdevice --disable-avfilter --enable-libfftw3 --disable-directfb --disable-joystick-menu --disable-lirc --disable-hdhomerun --disable-symbol-visibility --compile-type=release
> 
> 
> I can't see any good reason for configure to be setting the use of
> lib.exe (which just isn't going to work on a linux platform) with the
> above options?

Agreed.  But it does no harm - it's just noise.

> I played around for a while trying to get deptool to be a fake lib.exe
> but I'm WAY out of my depth and unsurprisingly that didn't work...
> 
> 
> Um.... so, I guess I'm asking - is this a bug in the main
> mythtv ./configure ? Or I can change this behaviour somehow.

It's not the bug that you're looking for.  But it should ideally be
fixed.

If you post the mythfrontend log I'll see what I can do to find a
solution for your Nuppel decoding.  Maybe it's just a dll naming
problem.

-- 
Lawrence