MythTV 0.21 is OUT

[fuzzybee]

Well, change 17079 to the svn adds proper Dolby tags to recordings, when using schedule direct. Now I have to wait for my patch to flow through to portage.

This is my first accepted mythtv patch, so I'm happy. I need to work on the next annoyance, jobs for items in the "to be deleted" queue still showing up and (presumably) still running.

Cool! Thanks!

[tld]

For any of you who occasionally get corruption in your mpeg TS files (some of which is inevitable for OTA recording) and have noticed that in 0.21 they cause nasty full-scale digital pops or chirps in the ac3 audio, see my patch here:

http://www.gossamer-threads.com/lists/m ... ers/329267

...this was a really ugly issue for me and that fixed it perfectly.

Tom

[DocterD]

anyone got already experience with the latest 0.22 trunk?

[GBob]

For any of you who occasionally get corruption in your mpeg TS files (some of which is inevitable for OTA recording) and have noticed that in 0.21 they cause nasty full-scale digital pops or chirps in the ac3 audio, see my patch here:

http://www.gossamer-threads.com/lists/m ... ers/329267

...this was a really ugly issue for me and that fixed it perfectly.

Tom

Nice, thanks for the link. I haven't tried it yet, but I have compiled it in.

A little side note, does gentoo have a good way, other than keeping the source and running make install, to develop applications? Ideally, I would like to work on source, test it, create a patch, and use that patch as part of an overlay with as little effort as possible.

[tld]

Nice, thanks for the link. I haven't tried it yet, but I have compiled it in.

You're welcome! There's actually an official changeset for that now, though it's functionally identical to my patch. It's linked from the bug report:

http://bugs.mythtv.org/trac/ticket/5220

A little side note, does gentoo have a good way, other than keeping the source and running make install, to develop applications? Ideally, I would like to work on source, test it, create a patch, and use that patch as part of an overlay with as little effort as possible.

Good question. I'd be interested to find that out as well. So far when I've been trying changes to mythtv, I'll use the ebuild application:

http://www.gentoo.org/doc/en/handbook/2 ... t=3&chap=6

...to separate the unpack, compile, install, and qmerge. That way I can change the source under /var/tmp/portage in between the unpack and compile steps. If I remember correctly, there's a file you need to delete (or something like that) to force a recompile if you make further changes and rerun those separate commands.

Sometimes I do that in conjunction with a separate copy of the mythtv source checked out from svn...doing 'svn diff' to create patches to apply to the unpacked Gentoo source.

Certainly nothing too streamlined to say the least.

Tom

[Growlizing]

Just dropping a note to say that I put in keywords today and updated to 0.21. Everything went smoothly, so thanks for the good work (at least I haven't noticed anything yet) :>

[tld]

You know...the more I read about peoples various issues in places like the mythtv-users mailing list and the like, the more I think that Gentoo is hands down the best distro for a mythtv system. Anyone else share this unbiased opinion.

Tom

[GBob]

You know...the more I read about peoples various issues in places like the mythtv-users mailing list and the like, the more I think that Gentoo is hands down the best distro for a mythtv system. Anyone else share this unbiased opinion.

Tom

If you limit the scope to mythtv only, then yes. My biggest gripe is, (and it mainly is with myself for not doing the maintenance,) there's always some other package which won't install smoothly or some pam issue which messes up permissions for everything. I then go searching the forums, find the problem and fix it, but still it is a pain. On the other hand, when I was updating every day (years ago) I kept running into similar issues on a daily basis, and I'd often have a broken system for a couple days while waiting for someone to help me out via the forums. I decided not to play that game anymore.

[depontius]

mythtv-0.21 has been ~arch for some time now.

Does anyone have a feel for when it's going to go stable?

Does anyone know anything about a "mythextras" package that is supposed to be the right way to bring in nuvexport? I see in this thread that some have tweaked an ebuild for nuvexport-0.5 to go with mythtv-0.21, but am wondering about the "official" solution.

Does anyone get acceptable results out of mytharchive? For me it tends to fail silently during transcoding, producing short disks that you don't know have a problem until you're all done. I've only been able to get reliable transcoding out of "nuvexport --transcode".

[GBob]

Does anyone get acceptable results out of mytharchive? For me it tends to fail silently during transcoding, producing short disks that you don't know have a problem until you're all done. I've only been able to get reliable transcoding out of "nuvexport --transcode".

Wow, I've never heard of this problem. I mean, the fonts in the menus may look a little weird (not anti-aliased, wrong size, sometimes stretched) but the video is always solid. So how about I tell you how I do things:
I keep the recording as a mpeg instead of a nuv
I load the cut list, create my cut points, and then use a lossless transcode to remove those sections
I add the file to mytharchive use SD/HD encoding profile and things seem to work nicely

My way removes several things that can go wrong, the first being nuv->mpeg. Disk space is cheap, no reason not to get some more and keep the files in a nice format when trying to go to DVD (furthermore, if the video is of the right size, no resizing in the transcode makes things much faster). Second, taking the cut points out of the mytharchive transcode step keeps things flowing nicely without any interruptions in the stream. Finally, the SD/HD profiles seem to be quite nice for most things (although if the video is the right size no reencoding is the fastest and works well too).

[TinheadNed]

I got a short disc when I selected DVD-R instead of DVD-RW when using a DVD-RW, if that helps.

[depontius]

I keep the recording as a mpeg instead of a nuv
I load the cut list, create my cut points, and then use a lossless transcode to remove those sections

How do you do these? Do you really mean that you have a capture card with hardware mpeg, as opposed to the cheap-o card that I've got, or is there some simple, reliable software step you throw in? As for the second step, I thought all transcoding was lossy.

[GBob]

I keep the recording as a mpeg instead of a nuv
I load the cut list, create my cut points, and then use a lossless transcode to remove those sections

How do you do these? Do you really mean that you have a capture card with hardware mpeg, as opposed to the cheap-o card that I've got, or is there some simple, reliable software step you throw in? As for the second step, I thought all transcoding was lossy.

Lossless (or almost lossless) transcoding only works on mpeg2 recordings. And yes, mpeg2 is only offered if your card supports it as a hardware encoder (which is a shame if you ask me). Last I knew mpeg2 encoder capable cards ran about $100. I guess my advice isn't going to be of much help. I have to 250 encoders (as well as a pinnacle 800i for HD) which do a great job. (3 separate computers, 750 gig storage space via nfs.)

[EmptyDoor]

mythtv-0.21 has been ~arch for some time now.

Does anyone have a feel for when it's going to go stable?

Does anyone know anything about a "mythextras" package that is supposed to be the right way to bring in nuvexport? I see in this thread that some have tweaked an ebuild for nuvexport-0.5 to go with mythtv-0.21, but am wondering about the "official" solution.

There doesn't seem to be an official release archive of mythextras even though it is mentioned in the release notes. However, you can get nuvexport with

svn co http://svn.mythtv.org/svn/trunk/mythextras/nuvexport

Then run 'make install' and symlink /usr/local/bin/nuvexport to /usr/bin/nuvexport
Works nice with 'nuvexport --transcode'

You need to install Net-UPnP (not in Portage): http://search.cpan.org/~skonno/Net-UPnP-1.2.4/
And MythTV needs to be running

Does anyone get acceptable results out of mytharchive? For me it tends to fail silently during transcoding, producing short disks that you don't know have a problem until you're all done.

Happens for me, too. Using analogue TV card

[gcasillo]

The last three times I attempted to update mythtv on my PVR box, the compilation basically stopped without an error with this output:

Code: Select all

In file included from ../libmyth/mythwidgets.h:20,
                 from ../libmyth/mythconfigdialogs.h:13,
                 from ../libmyth/settings.h:4,
                 from cardutil.h:5,
                 from signalmonitor.h:21,
                 from dtvsignalmonitor.h:9,
                 from iptvsignalmonitor.h:6,
                 from moc_iptvsignalmonitor.cpp:11:
/usr/qt/3/include/qimage.h: In member function 'bool QImageTextKeyLang::operator<(const QImageTextKeyLang&) const':
/usr/qt/3/include/qimage.h:58: warning: suggest parentheses around && within ||
g++ -c -pipe -march=nocona -fomit-frame-pointer -O3 -DNDEBUG -g -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wno-non-virtual-dtor -D__STDC_CONSTANT_MACROS -I/usr/include/freetype2 -D_REENTRANT -DPIC -fPIC  -DMMX -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DUSING_OSS -DUSING_H264TOOLS -DUSING_X11 -DUSING_XV -DUSING_XVMC -DUSING_XVMCW -DUSING_OPENGL -DUSING_OPENGL_VSYNC -DUSING_GLX_PROC_ADDR_ARB -DUSING_FRONTEND -DUSING_FFMPEG_THREADS -DUSING_V4L -DUSING_DBOX2 -DUSING_IPTV -DUSING_HDHOMERUN -DUSING_IVTV -DUSING_BACKEND -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_NO_DEBUG -I/usr/qt/3/mkspecs/linux-g++ -I/var/tmp/portage/media-tv/mythtv-0.21_p17637/work/mythtv-0.21/libs/libmythtv -I/usr/include -I../.. -I.. -I. -I../libmyth -I../libavcodec -I../libavutil -I../libmythmpeg2 -Idvbdev -Impeg -Iiptv -I../libmythlivemedia/BasicUsageEnvironment/include -I../libmythlivemedia/groupsock/include -I../libmythlivemedia/liveMedia/include -I../libmythlivemedia/UsageEnvironment/include -I/usr/qt/3/include -I/usr/X11R6/include -I/usr/X11R6/include -o moc_urlfetcher.o iptv/moc_urlfetcher.cpp
g++ -c -pipe -march=nocona -fomit-frame-pointer -O3 -DNDEBUG -g -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wno-non-virtual-dtor -D__STDC_CONSTANT_MACROS -I/usr/include/freetype2 -D_REENTRANT -DPIC -fPIC  -DMMX -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DUSING_OSS -DUSING_H264TOOLS -DUSING_X11 -DUSING_XV -DUSING_XVMC -DUSING_XVMCW -DUSING_OPENGL -DUSING_OPENGL_VSYNC -DUSING_GLX_PROC_ADDR_ARB -DUSING_FRONTEND -DUSING_FFMPEG_THREADS -DUSING_V4L -DUSING_DBOX2 -DUSING_IPTV -DUSING_HDHOMERUN -DUSING_IVTV -DUSING_BACKEND -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_NO_DEBUG -I/usr/qt/3/mkspecs/linux-g++ -I/var/tmp/portage/media-tv/mythtv-0.21_p17637/work/mythtv-0.21/libs/libmythtv -I/usr/include -I../.. -I.. -I. -I../libmyth -I../libavcodec -I../libavutil -I../libmythmpeg2 -Idvbdev -Impeg -Iiptv -I../libmythlivemedia/BasicUsageEnvironment/include -I../libmythlivemedia/groupsock/include -I../libmythlivemedia/liveMedia/include -I../libmythlivemedia/UsageEnvironment/include -I/usr/qt/3/include -I/usr/X11R6/include -I/usr/X11R6/include -o moc_hdhrsignalmonitor.o moc_hdhrsignalmonitor.cpp
In file included from ../libmyth/mythwidgets.h:20,
                 from ../libmyth/mythconfigdialogs.h:13,
                 from ../libmyth/settings.h:4,
                 from cardutil.h:5,
                 from signalmonitor.h:21,
                 from dtvsignalmonitor.h:9,
                 from hdhrsignalmonitor.h:6,
                 from moc_hdhrsignalmonitor.cpp:11:
/usr/qt/3/include/qimage.h: In member function 'bool QImageTextKeyLang::operator<(const QImageTextKeyLang&) const':
/usr/qt/3/include/qimage.h:58: warning: suggest parentheses around && within ||

Every time at this point, the hard drive light is on and the drive is working mercilessly. I waited thirty minutes before CTRL-C'ing to end the compile. The compile just seems to get stuck. No errors are spewed. Nothing. It just screetches to a halt there. This happened when attempting to update to both mythtv-0.21_p17435 and mythtv-0.21_p17637. I have a relatively new Core 2 Duo processor and mobo in this box. Never had issues with regards to compiling. Not like this.

Anybody have any ideas? Could it be related to a recent upgrade to gcc-4.3.1? I've not seen anything in bugzilla or elsewhere in the forums that matches this issue.

[EmptyDoor]

The last three times I attempted to update mythtv on my PVR box, the compilation basically stopped without an error with this output:

Every time at this point, the hard drive light is on and the drive is working mercilessly. I waited thirty minutes before CTRL-C'ing to end the compile. The compile just seems to get stuck. No errors are spewed. Nothing. It just screetches to a halt there. This happened when attempting to update to both mythtv-0.21_p17435 and mythtv-0.21_p17637. I have a relatively new Core 2 Duo processor and mobo in this box. Never had issues with regards to compiling. Not like this.

Anybody have any ideas? Could it be related to a recent upgrade to gcc-4.3.1? I've not seen anything in bugzilla or elsewhere in the forums that matches this issue.

I did notice that the compile of 0.21-p17637 was unnormally slow and resource-hungry (sometimes even the mouse cursor lagged!). This was on a Pentium 4 2.8 GHz. I'd recommend letting it run for at least an hour. You might also want to try checking if your system clock is set correctly.

[gcasillo]

Best I can tell, this may be a problem between gcc-4.3.1, AMD64 systems (mine is a Core 2 Duo), and mythtv with the emphasis on gcc-4.3.1. I was able to install mythtv-0.21_p17637 on my Pentium 4 3.0GHz without incident using gcc-4.3.1. However, I cannot get either p17637 or p17435 to install on my AMD64 install using gcc-4.3.1.

MythTV bug

Gentoo bug

[gcasillo]

After an update to gcc-4.3.1-r1, I successfully emerged mythtv-0.21_p17722. I believe the bug resided w/in gcc-4.3.1 (and possibly 4.3.0). Thanks to all devs for squashing this bug!