• Yakko
  • New member
  • Offline
  • Registered: 2007-11-07
  • Posts: 3

Topic: iPod functions

I'd like to see the following when using the iPod functionality:

a) Pause when the squeeze button activates (still put the Chumby in the control panels, just pause at the same time). Currently pausing takes 3 steps: squeeze button, Music, Pause.  I use my Chumby at work and that is too many fumbling steps when I recieve a call or someone walks in my cube.

b) overlay song names on widgets for a few seconds when the track changes.

c) enable setting star ratings on songs. This might be a limitation of the iPod usb interface, but it would be nice if you could hit the squeeze button (pausing the current track), go into Music and set the star ratings for the current song.

Thanks for all the hard work on the Chumby so far.  It's great.

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,197

Re: iPod functions

At this point, we're not planning on adding any iPod functionality that modifies the state of the iPod, which would include setting ratings.  Apple has recently made changes to the database format that makes it more difficult and dangerous to change outside of iTunes, and we're a bit hesitant to take on the risk of screwing up someone's iPod.

Apple has made it pretty clear that they will, over time, make it increasingly difficult for third-party applications to access the iPod - at some point in the future, we may have to drop support for the iPod.  We're already unable to support the iPhone and iPod Touch, and I expect that future iPods will follow the same pattern. Apparently Apple has recently filed a patent that would prevent an unlicensed device from even *charging* an iPod.

Your other suggestions are interesting - we'll look into them.

Duane's Website

  • Yakko
  • New member
  • Offline
  • Registered: 2007-11-07
  • Posts: 3

Re: iPod functions

Yeah, Apple is starting to develop the monopoly attitude about the ipod, it's sad.

One other issue, more of a bug then a feature request:

pick a playlist, set it to play random, hit play.  It always plays the first track in the playlist and then starts randomizing.

current workaround is to hit play, then the next track button.

  • Registered: 2007-11-19
  • Posts: 9

Re: iPod functions

I'd just like to be able to select 'artists' or 'songs' or 'genres' or something else besides just 'playlists'.  It's a bummer - I loaded some new tunes on my ipod, then brought the Chumby and my ipod to the in-laws for Thanksgiving.  I couldn't play the new music thru Chumby since I hadn't added the new music to a playlist.

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,197

Re: iPod functions

Well, it's a balance - should the chumby reproduce all of the functionality of the iPod *and* all of the other stuff it has to do?

From a practical standpoint, the chumby has an interesting problem. Unlike a real iPod, the chumby has to handle every database version for every firmware version, for every model of the iPod that it can support, wheres any given iPod only has to handle its specific version.  That means the chumby has to be even smarter than *iTunes*, since even iTunes forces you to upgrade iPod firmware and database versions when they're too old.

In order to do what you want, the daemon that manages the iPod would have to do a lot more work building the mappings from the database, which would result in a mount time about 3-4 times longer than it takes currenty, and substantially more memory.

I'll take a pass at it after my current project to see if there's some way to do this for some models - some iPod database versions maintain a table that might be used to quickly create these mappings, but some models, particularly the Shuffles, simply don't bother to create them.

Duane's Website

6 Reply by skada (edited by skada 2007-11-27 08:06:45)

  • Registered: 2007-11-09
  • Posts: 78

Re: iPod functions

If you support the Rockbox firmware for the iPod (and all the other players it supports), you'd only have to deal with one database. But, from what I can tell, iPod owners are the least likely to use Rockbox anyway, as they've generally paid a lot more for their mp3 players (and don't want to risk messing it up), and Apple's platform and GUI is pretty nice to begin with...

But, maybe there's a way to just use Rockbox's database that people could then just load on their players.

Actually, this is probably a stupid question, but why do you need a database anyway? What's wrong with the method you came up with for just scanning for mp3 files (for UMS mp3 players anyway)? I've been using your code for about a week now (with my shuffle hack) without issues using a USB flash drive (the only problem I've run into is that it doesn't always mount on boot, so you have to unplug it and replug it quickly before it's done starting up). But, I haven't tried it with my UMS mp3 player yet (and if it doesn't work, I guess that will be my answer to why you need a database...).

  • Yakko
  • New member
  • Offline
  • Registered: 2007-11-07
  • Posts: 3

Re: iPod functions

uggh. I have an 80 GB ipod. Scanning for every song would take forever. It's already slow processing the db!

Not sure which iPod the person having music not in a playlist has, but most of the recent (mine is a 5G and I think 4G had it to) iPods allow you to create a playlist on the go (in fact it shows up as the On the Go playlist).

Instructions here:
http://tech.yahoo.com/gd/ipod-itunes-cr … pod/166372

Not sure if the Chumby sees that playlist, I'll test at work.

  • Registered: 2007-11-09
  • Posts: 340

Re: iPod functions

Duane wrote:

Well, it's a balance - should the chumby reproduce all of the functionality of the iPod *and* all of the other stuff it has to do?

In my opinion, if most users have no need to have the chumby act as an ipod server, but only play music locally, it might make sense to remove the iPod functionality and replace it with one of two options:

1) Add hardware for an 'audio in' from the ipod, and have the ipod itself control everything.  This way allows other MP3 players to be used.

2) I'd be happier if you treat the iPods as memory sticks with MP3 files on them and create the track information from the embedded ID3 tags.  Then you can treat all memory sticks containing MP3 files equally .  You can still have a 'music server' (via HTTP) with this approach.  There are issues with this, such as caching the tracking information (to where?) and what to do about playlists, but I think it may be solvable.

wayn3w

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,197

Re: iPod functions

Scanning 8,000 files to extract ID3 tags is even *more* work, since, you not only have to do that, but *also* create the mappings.  At least with the database, that work has been done in advance by iTunes.  Plus you don't have any playlist information, since that's not incorporated in the tags, and you'd also have to scan the entire MP3 files to compute bit rate and duration (MP3 files don't contain that info in the headers).

"On the Go" playlists are not kept in the iTunes database until you sync with iTunes, at which point they get merged.

I don't know if the Rockbox solution solves the primary problem - does it contain a precomputed table mapping artists and genres to songs, or would the chumby still have to do that?  Of course, as you said, iPod users are the least likely to use Rockbox.

Caching precomputed data on the iPod is something we'd be very hesitant to do - it's not clear how you'd sync with the primary database when iTunes creates a new one (perhaps MD5 to detect the change?), and then we have the problem with Apple-formatted devices using HFS+ file systems - the chumby only supports read-only access to HFS+ mounts.  We don't have the storage to keep a database cached on the chumby itself.

Duane's Website

  • Registered: 2007-11-09
  • Posts: 78

Re: iPod functions

Ah, ok. I forgot that there are players out there that hold that many songs - your script works really well for 100 songs (that's as many as I've tried so far) :-)

Rockbox has genres, albums, artist, composer, year, and user rated as categories. I assume they are precomputed - every once in a while, it says "updating database". I've tried to take a look at the internals of the database, but I haven't even been able to find it yet in all the source (I've only spent a few minutes on it, though) :-)

Wow, the whole thing sounds messy. It's a shame that all the databases are different - they all pretty much do the same thing... Anyway, I'd be cool with just an "audio in" jack. The player is right there anyway, though it would be really cool to have a "now playing" widget, send your played songs list to Last.fm, etc.

  • Registered: 2007-11-09
  • Posts: 340

Re: iPod functions

Duane wrote:

Scanning 8,000 files to extract ID3 tags is even *more* work, since, you not only have to do that, but *also* create the mappings.  At least with the database, that work has been done in advance by iTunes.  Plus you don't have any playlist information, since that's now incorporated in the tag, and you'd also have to scan the entire MP3 files to compute bit rate and duration (MP3 files don't contain that info in the headers).

"On the Go" playlists are not kept in the iTunes database until you sync with iTunes, at which point they get merged.

I don't know if the Rockbox solution solves the primary problem - does it contain a precomputed table mapping artists and genres to songs, or would the chumby still have to do that?  Of course, as you said, iPod users are the least likely to use Rockbox.

Caching precomputed data on the iPod is something we'd be very hesitant to do - it's not clear how you'd sync with the primary database when iTunes creates a new one (perhaps MD5 to detect the change?), and then we have the problem with Apple-formatted devices using HFS+ file systems - the chumby only supports read-only access to HFS+ mounts.  We don't have the storage to keep a database cached on the chumby itself.

We agree that supporting iPods is difficult and will be more difficult with newer models.  But what I'm asking is whether it is worth it?  Is the pool of iPod users who can and will use it with Chumbys larger or smaller than the people with USB drives or MP3 players that look like USB drives (FAT32 formatted)  that want to use the Music functionality?  Are these people willing to sacrifice some space on the device and some initial scanning time in order to be able to use the device with the Chumby?

Call me naive, but a prototype using the HTTP server code in the Chumby repositories and the id3lib could function almost identically to the chumbypodd.  I believe the control panel would be able to use it, and it would be workable after the initial scan.