wonkablog

I’ve been having a lot of fun with my mythbox lately. I’ve learned some really cool stuff about Myth, MPlayer, LVM2 and multimedia in general that is really helping to polish my setup. Add to that the fact that I’ve been working on dvd::bend quite a bit lately, and getting some bugs taken care of, and things are really adding up. I also finally took the plunge last week and bought my first 750 GB harddrive. I’m up to 1.6 TB of space in my server now (5 harddrives in one box), and I haven’t even hit 50% capacity yet. I’m sampling a little bit from all my TV series and getting them on there, so I can at least watch something from everything I have. Eventually, somewhere down the road when I have lots more space, I’ll have everything completely archived. For now, I’m still experimenting and getting used to the setup. It’s getting pretty nice.

Here’s some of the cool little stuff I’ve found out recently.

mythtv custom menus

I didn’t know this til just the other week, but the design for the menu layout that Myth uses is all in XML files, and right there in the themes directories (/usr/share/mythtv/themes). That said, you can customize them all you want! Just read the docs, and you’ll be up and running in no time. It’s really simple. It took me just a few minutes to simplify my main menu so I can jump to the TV recordings and MythVideo really easily.

mythvideo gallery view

I’m really having fun with this one. There’s a few things I’d change, but for the most part it works great. Here’s what my layout looks like right now:

mplayer + xvmc + high motion

I just barely discovered this tonight. One of my frontends is a Pentium 4 1.6 gHz, which does plenty well. You really don’t need that much horsepower to play back video. It’s got an older nvidia AGP card in there which works just fine with s-video out. The only problem I have is that there is sometimes a slight stutter on the video with some high-motion scenes. I’ve actually started to get used to it, but then I found out that using the XvMC video out option really makes things much smoother.

At first I was just playing with it to see if I could get the CPU usage down. It was only dropping by about 10%, which wasn’t that great, especially since it was still running high … around 35%. Turns out I had cpufrequtils set to use the powersave governor, so my CPU was only running at 400 mHz. Whoops. I bumped it back up to full speed, and mplayer dropped down to around 10% total.

But, even then, at the lowest speed, the video looked gorgeous. I’ll admit it might have been my imagination, but those motion blur issues seemed to go away. I was so surprised by the results that next I ran it through the Star Trek test (which everything has failed), and played back some Deep Space Nine. Normally I’ll test TNG since I’m extremely picky about the video quality on that one, and I’ve seen them enough that I can notice video artifacts more easily, and this was only the 2nd time I’ve seen this DS9 episode. But, it still looked nice. I could notice some small amounts of blur, but it was pretty minimal. So, who knows, that solution might work well for everything. We’ll see. I’m feeling pretty optimistic about it, and at the very least it works great for my older TV.

mplayer + audio delay

Before that, I was taking a break and watching some A-Team. Great stuff. On one episode, the A/V was off just slightly. This has always plagued me in the past, and it’s one of the reasons I don’t bother with encoding files. Also, this has happened before on another Universal disc (of all the DVDs I have, they have the most problems … they are rare, admittedly, but that studio is still the winner). I remembered reading somewhere about adjusting the audio delay with mplayer, so I checked the man page. You just use + and - keys on the keyboard to adjust it by 1/10th of a second each way, faster or slower. Played around with that, and the A/V was back in perfect sync. So, I mapped my channel up / down keys on my remote to do that in case I ever run into that problem again, and now that’s all fixed too.

matroska saves the day, and disk space

This is another cool one I noticed last week. This is all anecdotal evidence, so YMMV, but I’ve noticed that Matroska files are consistenly smaller than AVIs. About 8% smaller, in fact. I noticed that quite by accident while playing around with some encoding files. At first I figured I had done something wrong, but the results proved the same after quite a few tests. That is a lot of overhead for AVI, sheesh. Just one more reason to love and use Matroska.

Seems like there was something else, but I can’t remember now. Ah well. Anyway, I was hoping to get all those random thoughts down sometime, so there you go. Lots of fun playing around with this stuff. I’m pretty blown away by how well it’s working and how polished the whole thing is getting. Once I’m done for good, I’ll be sure to document how to reproduce the entire step in detail. Good times.

Another small mplayer tip, that I had to google for. When building MPlayer with XvMC support, so that it will use the video card’s hardware for MPEG2 decoding (and therefore, less CPU load on your box), mplayer -vo xvmc alone won’t work. You have to add -vc ffmpeg12mc as well, to force mplayer to use that codec for playback.

And, of course, I just noticed it says that right there on the man page. Whoops. So much for RTFM.

Anyway, if you like to use profiles, it makes things easier. Just drop this in ~/.mplayer/config and then do mplayer -profile xvmc movie.avi

[xvmc]
vo=xvmc
vc=ffmpeg12mc

I really can’t tell much difference in CPU load myself, since I’m running a fast box, but if you’ve got an older box with a decent (nvidia geforce 4 and up), give it a try. It’ll only work with MPEG2 videos, and the nvidia-drivers as well. I believe it works on the Intel i810 video cards too, though I don’t have one I can test it on.

I should clarify on my last post about Freevo and MPlayer fighting over LIRC events, since after some more research, I figured out what is going on. Here’s the story.

Freevo, when it uses mplayer to watch a movie, will pass some extra options to the command along with whatever you specified. That in itself is extremely annoying, I think, since you already have a config file for mplayer in ~/.mplayer/config, but the fact represents the philosophy that Freevo has of trying to configure everything all in one place instead of relying on original configuration files. That philosophy wouldn’t be so horribly bad if two things didn’t come into play: you wanted to use your original customizations, and freevo limits your options of the original program by trying to provide such a service. That second one is what I ran into.

Two of the extra options that Freevo sends to mplayer when starting a movie are this: disabling lirc support (-nolirc) and adding slave mode (-slave). If you haven’t heard of slave mode, what it does is when you run it, it will listen for commands you can still pass to the terminal to control mplayer. Some examples would be, display on screen information, skip forward a chapter, seek forward / back, quit, etc. Now if you built mplayer with lirc support, you can directly access all those commands with a simple lircrc file. As an example, I have an old one hosted here.

Now, I should also mention that LIRC is setup so that it will respond to whatever events are pressed, based on what programs are running. So, you could have VLC and MPlayer and MythTV all running on your desktop at once, assign commands to each of them in your lircrc files, and switch between the applications, use your remote, and not have it affect the other programs. Sounds great, right? This is where Freevo starts to change things around.

Remember that Freevo disables LIRC support for MPlayer in the command line. There’s a reason for that - it is capturing all LIRC events being sent, not just the ones to Freevo. Whether this is done by design or not, I can’t be sure. For all I know, it could be a limitation of pylirc. Either way, Freevo is programmed from here on out to take on the role of master of remotes, and process any events you press to the programs you are using. For someone like me, who was gone out of his way to tweak his current setup so that my remote works in *any* MPlayer session, doesn’t like having to re-setup the events in a watered down version through Freevo configs a second time around.

If you want to send a command to mplayer through Freevo, here is what you would have to do: edit your ~/.freevo/local_conf.py and add events for each Freevo event plus the slave command to send to mplayer. Examples can be found in the FAQ:

EVENTS['video']['PREV'] = Event(VIDEO_SEND_MPLAYER_CMD, arg='seek -600')
EVENTS['video']['NEXT'] = Event(VIDEO_SEND_MPLAYER_CMD, arg='seek 600')

Now to be honest, I wouldn’t mind that too much if it weren’t for one simple fact — LIRC gives you more options. With Freevo’s way of doing things, I can’t send multiple events on one keypress, alternate options on keypresses, or set the repeat time. Nope. I can just send slave events, and that’s it. It’s making me pretty frustrated, too.

To be fair to Freevo developers, I honestly don’t know if this is a design flaw of something else or a known implementation. It could be that pylirc is written to listen to all events and not distinguish between programs, and Freevo had to find a way to filter them out. I’m not sure, and I’m going to try and find out for sure, and hopefully see if there’s a way to disable the option.

There is an alternative option. You could setup irxevent to send commands to Freevo directly, but that is kind of sluggish, I’ve noticed, and I don’t really like it.

Also, if you weren’t so anal as I am about your LIRC events, you could just map your slave commands through Freevo to MPlayer just fine and be happy with it. I’m pretty picky about my settings though, so my rant would only affect a very small minority.

Anyway, the fact is that I absolutely love Freevo. It is a *great* little program, perfect for my needs. I just really dislike how it hardcodes some settings into the program like passing extra mplayer commands, and then doing stuff like reinventing the wheel for my LIRC setup. Hopefully there’s a way around this stuff without getting too deep into the code. In the meantime, I switched back to MythTV + MythVideo which is a nice little frontend to browse your media files, but doesn’t come near the number of cool options that Freevo has for customizing your display. At least I can watch my movies, though.

I’ve been playing with MPlayer, Freevo and LIRC most of all day today, and made some small progress. For one, I found a lovely nasty bug in the latest Freevo, where if I hit the right or left buttons on my remote while watching a movie in mplayer, the event gets sent to both freevo and mplayer. At least I think that’s what it’s doing. What actually happens is that mplayer quits, and I’m blaming Freevo since it works fine by itself outside of that.

Of course, the way Freevo hides and then adds it’s own set of mplayer commands drives me absolutely bonkers. One it has in the latest release is to add -nolirc meaning none of my remote commands are going to work at all. However, I worked around that with mplayer-resume, and I’ll write about that later.

This is the cool thing I stumbled on. Among mplayer’s slave commands is one called osd_show_property_text which will display on screen (osd = on-screen display) the property text of something. In this case, I wanted to display the filename that was playing, since with dvd-bend, I eventually rip all my files to the title of the show. The problem I ran into was I couldn’t figure out how to get it to display the filename. Here’s how, though: just map the command to osd_show_property_text “${filename}” in your LIRC rc file.

Here’s an example from my ~/.mplayer/lircrc that I added:

begin
prog = mplayer
button = green
config = osd_show_property_text “${filename}” 500
end

In the case above, my StreamZap USB remote has four colored buttons on the bottom, and I have an event press called ‘green’. So when I press the green button, it tells MPlayer to display the filename. I added 500ms as an optional duration time, since the default is really short.

A picture is worth a thousand words, though, so here’s what it looks like on your display.

I should mention that I’m sure that there are lots of other variables you could display on screen, but I can’t figure it out. Actually, now that I think about it … Okay, I figured it out. Run mplayer -input cmdlist (by the way, I hope by now you’re running either SVN of MPlayer or a really recent snapshot, you always should), and at the bottom you’ll have a table called available properties. Just do the same command as above, putting the variables in the same format. Another example, would be to display the time position: osd_show_property_text “${time_pos}” I don’t know if they all work, but I tried about half a dozen and they all did, so go wild.

One last thing to mention … if you’re just using the keyboard, press capital I to get the same thing.

Now if I could only get my Freevo + MPlayer + LIRC issues solved, I’d really be good to go .. I’ll have to post another time on my issues / updates with that arena, though. For now, it’s fun enough just to get MPlayer decked out.

Here’s something I had to look up today that I don’t wanna dig around for anymore.  The default settings for MPlayer to seek backwards and forwards is to jump 10 seconds at a time.  Today I had to do a lot of jumping on DVDs, mostly to find title tracks on short cartoons, and 10 seconds would often skip right past it.

You can change the defaults if you want, by creating an input configuration file for events.  Just edit ~/.mplayer/input.conf and add the event name, then the command, one per line.  Here’s what I added to make mine jump only 4 seconds instead:

RIGHT seek +4
LEFT seek -4

For the actual documentation, check this out.

The bug has once again bitten me to get all my multimedia on demand, even though it is an enormous time-consuming and costly process. This is probably round three or four for me trying to do this. This time around, things are a little different. Instead of ripping and saving everything from my entire collection, I’m going to try and just archive the stuff that I consider a novelty, or any cartoons that are short in nature. I’m doing it as a bit of a test run for a couple of reasons — to see how much time it will take, to work out a few bugs in the system, and to find out if I’ll actually bother watching anything.

So, right now, I’m working on both Looney Tunes and all my Walt Disney Treasures DVDs. Even that stuff alone is going to take up a massive amount of space, since I don’t re-encode the video (read archives for why, long story) or audio. Right now, Ive only got a little over 500 gigs to spare, with close to another terabyte that I can slap in if I think this is going to work. In the end, I’m going to have to buy either 750g or 1tb harddrives to hold everything, but I’m trying not to think about that just yet.

Anyway, onto the joy of ripping, encoding and muxing. I’ve dregged out my old dvd ripping project, bend, and dusted it off and started poking at it again. I can’t believe how much work I put into this thing to start with, it works *amazingly* well if I do say so myself. It makes ripping and archiving TV shows on DVD incredibly simple. I only had to add on a few small features as issues cropped up with my new goals.

First of all, I had always had it hard-coded to re-encode the video to MPEG4. In the database, I had an option to leave it alone as MPEG2, but the code wasn’t using that. So, I added that and set the default to not re-encode. The next problem I ran into was that on the Looney Tunes discs, I found some tracks that multiple audio tracks: both different languages and commentaries. This would cause problems because when you rip the VOB from the DVD to the harddrive, I use mplayer along with -dumpstream -dumpfile, and it snags all the audio tracks. Using that method, there’s no way to single out just one audio track (to be more specific, passing -aid 128 or -alang en doesn’t do anything). The only way to do that is to actually re-encode the video (or audio) and specifically select the audio track, which I don’t want to do, since it causes A/V sync issues on cartoons because of variable framerates.

To solve the problem, I poked around at Matroska and the mkvmerge tool a little bit. I had remembered seeing once that you can tell it which audio tracks to use when creating a new video file. Finding the track ids is simple, just run “mkvmerge -i” on the MPEG-2 .vob file. Here’s a sample output of one with multiple tracks:

steve@flick ~/media/dvds/Looney_Tunes $ mkvmerge -i season_1_disc_4_track_15.vob

File ’season_1_disc_4_track_15.vob’: container: MPEG 2 program stream (PS)
Track ID 0: video (MPEG-2)
Track ID 1: audio (AC3)
Track ID 2: audio (AC3)
Track ID 3: audio (AC3)

Now, you’ll see there’s only one video track, so that’s not a problem … matroska will just use that one by default. But since there are three audio tracks to choose from, it also uses the default, being the first, which is always another language or a commentary track (so far). In fact, my experience has shown that in every case where there are multiple audio tracks, it’s always the last one that I want. There have been some corner cases on a few individual episodes where that rule of thumb doesn’t apply, but it’s been something like one for each disc, which would be something like one out of every 15 to 20 episodes. As a matter of QA, I have to individually go back and play each muxed video to make sure the default of using the last audio track was what I wanted. Slightly time consuming, but not really a big deal, and I don’t know of any other way to get more details on which audio tracks are which. It just occurred to me that I should probably look into using mplayer with some verbosity flags. Oh well.

Another problem I ran into was that mkvmerge itself is picky as to the order of passing arguments. If I didn’t do things in the right order, then all the audio tracks would be selected. Kind of annoying. I vaguely recall reading something about that in the man page before, but I didn’t bother looking through there again. Instead, I figured up mmg, the wxwindows GUI to mkvmerge and watched how it did it. For the record, here’s a sample of a correct execution:

$ mkvmerge -o foo.mkv -a 2 season_1_disc_1_track_3.vob

In that example, the -a argument is for the audio track, followed by the number.

I also changed the database around, adding a new table called ‘episode_tracks’. When I rip the DVD for the first time, bend will check the number of audio tracks, and store them in the database. On the web frontend, where you edit the track titles, I also added an option to select the audio tracks on a per-episode basis. You can also set the default track # for the entire disc, if you want, to change all the episodes at once.

I should note that in all the DVDs I’ve seen, Looney Tunes seems to be an exception to many rules. Most DVD series aren’t even going to have multiple language tracks or commentaries. And even if they did, I don’t think they would have so many. I’m just glad that I happened to use this one first, so I could get the workarounds coded.

Something else I changed in the code, when muxing into Matroska, is I now pass the –title call along with the series and episode titles, so that they get written into the container as well. I’m not sure if I can get MPlayer to display that, but it might be kind of nice sometime if I wanted to recall what the title was, and just hit a button on my remote — I wouldn’t have to do something funky like check the filename, instead it would just be all right there.

Here was something else that was funky. My DVD drive in my desktop box was having issues ripping discs with MPlayer. I was getting some IDE error messages like this:

Buffer I/O error on device hdb, logical block 20278
Buffer I/O error on device hdb, logical block 20279
hdb: media error (bad sector): status=0×51 { DriveReady SeekComplete Error }
hdb: media error (bad sector): error=0×30 { LastFailedSense=0×03 }
ide: failed opcode was: unknown
ATAPI device hdb:
Error: Medium error — (Sense key=0×03)
(reserved error code) — (asc=0×11, ascq=0×05)
The failed “Read 10″ packet command was:
“28 00 00 00 4f 36 00 00 02 00 00 00 00 00 00 00 ”
end_request: I/O error, dev hdb, sector 81112
Buffer I/O error on device hdb, logical block 20278

First, I looked at my kernel to make sure my config was okay, and I flipped on a few more generic flags to see if that would help, then rebooted into the new kernel. It didn’t do anything. The drive would read for a few megabytes, then freeze on some titles. It seems like also it wouldn’t matter which track or disc it was on … it would just poop out after a certain amount of ripping.

I thought about heading down to PC Club and dropping $50 on an SATA DVD burner, thinking that having a drive that didn’t use IDE in the first place might be the solution. I can’t afford to buy more hardware right now though, so I kept poking around. At the same time, on the Walt Disney Treasures DVDs I was ripping (Tomorrow Land rocks, by the way), a lot of them have introductions by Leonard Maltin. I’ve got nothing against the guy, but I certainly don’t want his or anyone else’s face on my screen telling me what I’m about to see and then showing off the coolest scenes right before I’m going to watch them. So, I had to add another option to dvd-bend to let me say which chapter I wanted to start the ripping at. Incidentally, once the code was finished, I tried it on my desktop … and my IDE issues went away. As a result, I went ahead and hard-coded it as well to default to add ” -chapter 1 ” to the mplayer dumpstream command (if none was specified) so that my drive would always work. So far, it’s done great — no more ripping issues.

Once again, just for the record, here’s what I used as a workaround to my faulty drive to properly rip a DVD track:

$ mplayer dvd://3 -dumpstream -dumpfile track_3.vob -chapter 1

That’s pretty much it so far, as far as changes. That alone didn’t take too much time at all, just a few hours. I’m still working on setting up subversion on my live server so I can share the code if anyone wants to look at it. In the meantime, here’s the output of bend as I add a new series to the database, and rip it, so you can see how it works

Well, my box at home is working again, and to prove it, I bumped a new subversion snapshot of MPlayer into the tree this morning (1.0.20070622). Please note that I made absolutely zero small, minor or other changes to the ebuild, so don’t look for any fancy cleanup other than it’s the most recent code from upstream. The reason I did that was to get the open security bug taken care of, and I can always go back and clean up the less important stuff later.

As far as working on Gentoo stuff goes, I’m planning on taking things slowly. What happens everytime is that I’ll stretch myself too thin, and it quickly becomes un-fun having so much stuff to do, so I need to take a break. My approach this time, I think, is going to be to try and focus on one application at a time, get it completely cleaned up and taken care of, and maybe get some documentation written on it. After that, I can move onto another application and do the same thing. It makes things much easier when you’ve attacked a set of ebuilds for one program and cleaned them up as much as possible, for when you have to come back later and change something it only makes it that much easier.

The first app I want to start on and attack completely is abcde. It’s a great little CD ripper and encoding app, and the more I use it, the more I realize how awesome it is. I’ll write more about it later, though.

I’m also going to cut back on my IRC usage quite a bit as well. One thing I realized I didn’t like when I turned on my box the other day, was that I kept wanting to “check in” on IRC and IM as I was wondering around the house getting stuff done. That kind of nagging thought really bugs me, so I’ll probably only be online if I’m actually sitting at the computer doing something.

Anyway, I’m planning on working on some Gentoo stuff this weekend, so if you have anything in particular you’d like some attention given to, just let me know. I’ll be hanging out in #gentoo-media and #gentoo-mythtv.

Good news. The folks at MPlayer have forked libdvdnav, the library responsible for navigating menus on DVDs.  Upstream has been dead for quite some time now, but it’s still widely used and it’s a shame it hasn’t been getting the loving care it deserves.

There is already a new mailing list and subversion repository for the forked version.

Hopefully we’ll get to see some improvements and modifications real soon now.  If anyone can handle the task, it’s those crazy mplayer devs.  Thanks, guys.

Right after I complained about how I don’t like blogging about bumps in portage, here I am writing another post about that same topic.  Well, this time this one is a package addition, so that doesn’t count, right?  Oh, who am I fooling.

Something I’ve been meaning to mention is that I added a new library to the tree the other day, media-libs/libnut.  NUT is a container format being developed by ffmpeg and mplayer developers.  At least, that’s what the multimedia wiki page says.

And now you know just about as much about as I do.

Actually, NUT is something I see mentioned all over the place, and I was always curious … where’s the code?  Where’s the packages?  Apparently, they’re in subversion.  So the ebuild is just the latest subversion snapshot.

There’s really not much you can do with it.  You can create a NUT file with nutmerge, though the video has to be MPEG4 and the audio MP3.  Watch out for funky errors, too.  It does work fine with MPlayer, too.  There’s no nut use flag on that ebuild, since I didn’t really feel like adding one for one thing, and since the library is in development as well.  But, if you install it, mplayer will automatically detect and add support for it.

Go on, have fun with it.

I’m really starting to dislike me writing blog posts about stuff that I bump in portage, and hopefully this will be the last one.  Actually the only reason I’m doing this one is because I want to get the ebuild tested and as many bugs fleshed out as I can.

I started working on an ebuild for an SVN snapshot of MPlayer about a few weeks ago.  Upstream doesn’t do point releases very often, which is fine since they provide daily snapshots and they are pretty stable anyway.  It does make it a little hard on people like me though who are sometimes wanting something a little more recent.

Well, I think the complexity and time it took to put this thing together beat that desire out of me for a while.  MPlayer in itself is a beast, though a lovable wonderful one, and writing an ebuild for it is not the easiest thing in the world.  In fact, this was the hardest thing I’ve ever had to put together.  I have to give a lot of thanks to Lu (lu_zero) who not only gave me the green light to go through with this crazy idea, but mentored me quite a bit on what I was doing wrong and how to fix it.

I really don’t feel like going into details, so I’ll just summarize and say that there’s a new version in the portage tree, and it adds lots of use flags and should fix a lot of bugs.  If you do find problems with the ebuild, please comment about it in this forum post and I’ll try to take a look at it.  I have spent at least a combined total of 20 hours working on this ebuild, and I want it to be nice and clean.  Well, that, and I want to move onto other stuff, too.

So, lemme know if you find any problems.  Thanks, guys.