announcing jukebox - an mp3 player for pyhme

I have just put up on GIT a python MP3 player that runs under wmcbrine's pyhme framework. Several of the design features for this were "borrowed" from harmonium, and I would like to acknowledge that product and its authors. I just needed something that wasn't java-based.

I've mentioned that I have been working on this for some time now, and since I just recently solved the problem I had with it not working under pyhme 0.19, I decided it was time to release it. Even though I am calling it 1.0, it's somewhat early in its testing phase. Get it from the link in my signature and give it a try.

One note - I wrote it to support HD resolution only. If there is sufficient outcry for SD support, I'll consider it

1. A more sophisticated screen saver. A blank TV screen may be misinterpreted as being off.

Click to expand...

I can look into this. I was earlier thinging of having the album artwork bouncing around.

2. Album art lookup / refresh.

Click to expand...

I'm not sure what you mean here. I simply show what's in the mp3 file. I don't think I want to get into updating the mp3 file.

3. Lyrics lookup.

Click to expand...

I'd have to do some research here. I'm not currently aware of a web site that let's me retrieve lyrics. If I could find one (or if you know of one) and it has a reasonable interface I might be able to do something here

I'm not sure what you mean here. I simply show what's in the mp3 file. I don't think I want to get into updating the mp3 file.

Click to expand...

That's not what I was suggesting. Galleon simply looks up likely album covers on the web based upon the artist and displays them. Of course, most of them do not have anything to do with the current song, but it does present a montage of the artist's work.

I'd have to do some research here. I'm not currently aware of a web site that let's me retrieve lyrics. If I could find one (or if you know of one) and it has a reasonable interface I might be able to do something here

Got a chance to try this out the other day. Nice work. I like what you've done (having been a Harmonium user, I can see the resemblance).

Looks like I've got some work to do to clean up/restructure the metadata of my music to make it more "Jukebox-friendly"... especially in the area of "Album Artist vs. Track Artist" and Album Art (image size consistency). A couple of questions/comments...

1) I've got a lot of compilations that have many different artists. Right now, most of these have "Various Artists" in the Album Artist field - is it expected that Album Artist would be blank for this type of Album so that it falls to/dsiplays Track Artist? Any chance of a configuration option to change the order in which the artist fields are used?

2) What is the optimal image size for Album Art display in Jukebox? While I'm pretty good about making sure all of my audio files have image art, I'm all over the board in terms of the size of the image... which becomes painfully obvious when the player doesn't re-size them to a standard size.

3) I like the fact that the "Next Track" is displayed however I feel like it should be set apart more from the currently playing information. Perhaps it could be moved to someplace away from the main info section or displayed in a smaller font (or both).

4) Any chance for more built-in support for pre-existing (m3u) playlists? I found that I could play my pre-existing playlists by copying them into the jukebox\playlist directory and renaming them to .jpl files. I'm wondering if there is an easier way.

Got a chance to try this out the other day. Nice work. I like what you've done (having been a Harmonium user, I can see the resemblance).

Looks like I've got some work to do to clean up/restructure the metadata of my music to make it more "Jukebox-friendly"... especially in the area of "Album Artist vs. Track Artist" and Album Art (image size consistency). A couple of questions/comments...

Click to expand...

Glad you like it. I tried to answer your questions below.

1) I've got a lot of compilations that have many different artists. Right now, most of these have "Various Artists" in the Album Artist field - is it expected that Album Artist would be blank for this type of Album so that it falls to/dsiplays Track Artist? Any chance of a configuration option to change the order in which the artist fields are used?

Click to expand...

I tried various ways of dealing with this and what I ended up with the following: if both the track and album artist are specified, then those values are used. If one or the other is missing, then the value that is present is used for both. If both are missing, a value of "<unknown>" is used. Thus if you don't have the album artist as in your example, it should use the track artist instead.

2) What is the optimal image size for Album Art display in Jukebox? While I'm pretty good about making sure all of my audio files have image art, I'm all over the board in terms of the size of the image... which becomes painfully obvious when the player doesn't re-size them to a standard size.

Click to expand...

Art larger that 320 x 320 is reduced to 320 x 320 when the cache is built - it is one reason why the cache building takes so long. Art smaller that 320 x 320 is left unchanged. When I was developing, I noticed that a few of my songs weren't displaying art. When I looked, I discovered that these songs had bitmap artwork. I replaced it with jpg and it worked fine. I never looked any more into this, so for now at least I would recommend jpg artwork.

3) I like the fact that the "Next Track" is displayed however I feel like it should be set apart more from the currently playing information. Perhaps it could be moved to someplace away from the main info section or displayed in a smaller font (or both).

Click to expand...

Not commiting to it, but I'll consider it.

4) Any chance for more built-in support for pre-existing (m3u) playlists? I found that I could play my pre-existing playlists by copying them into the jukebox\playlist directory and renaming them to .jpl files. I'm wondering if there is an easier way.

Click to expand...

All I really need in a playlist file is a list of fully qualified path names. These are used to index into a dictionary I built that gives me back object references. Perhaps I can read in alternate playlist formats, but if they are changed in any way through the playlist editor screen, they will be written out as jpl files. Alternatively (and this might be simpler) I could write a conversion tool. Let me think about this one too.

Thanks again for another great app!

Click to expand...

An update on what I have been doing

1) I have implemented the screen saver ar lrhorer has requested - instead of a blank screen, the artwork for the current song moves around on the screen (if no song is presently playing, the application icon is used instead)

2) I have implemented a safeguard - if you try to exit by pressing left form the main menu while music is playing, you will be asked to confirm with a thumbsup. This prevents you from quickly hitting left-left-left rising up throught the menus and hitting it once too often and exiting the app.

3) I am working on lyrics retrieval. Not sure how it's going to mesh in with the main application yet. I am also having some difficulty because you don't always get well-formed HTML back from some of these web sites and I don't like the work-arounds.

GIT hasn't been updated with these yet - I am going to wait a few days to see how the lyrics retrieval progresses. If it looks like it will be a while before that will be done, I'll update with what I have done so far rather than wait for that work to be completed.

I have updated github with version 1.0a of jukebox. I haven't incorporated lyrics yet and am not sure if I will. The algorithm for retrieving lyrics is too non-deterministic for my liking.

What I HAVE implemented are the better screen saver and exit safeguard as described in the above post. I also now allow for the direct reading of m3u playlist files in addition to my own jpl files. A few caveats with using m3u files: 1) if they are modified within jukebox and then saved, they will be written as jpl files, not m3u files. 2) jukebox is looking for a fully-qualified file name within the playlist file. Depending on the way you have file systems mounted, the same file can have different paths on different systems. If you run jukebox on a system different from where you run your normal media player, the m3u file will possibly not work.

I haven't incorporated lyrics yet and am not sure if I will. The algorithm for retrieving lyrics is too non-deterministic for my liking.

Click to expand...

Well, there is no way the lyrics will always be available, and Galleon certainly was not always able to obtain the lyrics to any given song, but sporadic retrieval is better than none at all. IMO, of course.

This error is coming out of mutagen - most likely it is an ill-formed MP3 file. I have updated github with a new BuildCache.py - I added a try block around the mutagen call. The file still cannot be parsed, but now it will be identified, and even better - it will be skipped and the cache will continue to build without the offending file(s).

Again - this is probably an ill-formed MP3 file. IN this case, it looks like it has bad image data.

I have posted a new version on github. This adds a try block around all of the PIL/resizing logic. If the PIL logic fails, the file is not skipped, but it will be assigned default album artwork.

I have no good way of testing this fix. I DID make sure it still generates the same cache file (checksums equal) as the old version did when the files do not have any bad data. I don't know, however, the exact issue with your file that caused PIL to fail. Give it a try and let me know how it goes.

Finally got around to trying this ... pretty nice. Although I hate apps that show me how messed up my metadata is.

I currently use Galleon's music player primarily for the iTunes app, which automatically pulls my playlists out of my iTunes library so I don't have to maintain a separate set of files (I just copy the XML file from my PC to the Linux box every now and then and do a global search/replace to switch the path).

Nice looking app, though! It took about 20 minutes for BuildCache.py to process my 5,673 files ... only two errors on album art resizing.

I currently use Galleon's music player primarily for the iTunes app, which automatically pulls my playlists out of my iTunes library so I don't have to maintain a separate set of files (I just copy the XML file from my PC to the Linux box every now and then and do a global search/replace to switch the path).

That might be a bit too much to handle. Send me your output and I'll look at it, but it might just be too much to handle. With 141000+ files, your cache file is probably just under a gig. I think most people have <10,000 files and that was the scale I had in mind when I wrote the program

That was my response, too. If we assume 2 minutes per song (which may be too conservative if he has a lot of classical music), that's 195 days worth of music running 24 hours a day. The way that I listen to music, it's more like 195 years!