Maybe your iPod connected in USB 1.1 mode. Mine likes to do that randomly..

Alternatively maybe the hard drive in the 160GB model is slow. I'd say to read the metadata from 130GBs of files would take roughly 20 minutes at the same speed as the 80GB model.

Anyway, the metadata is cached so it won't do that again unless you decide to change the entire contents of your iPod in one go.

Hmm.. How do I tell when my Ipod has connected through usb 1.1? (I didn't know this was possible)

Whenever I try to refresh ipod metadata or load library I'm now getting a "cache read was aborted" error.

Hello, I don't know if this qualifies as a "bug" (it's more a misleading error message). I was trying to send an album to my ipod from an external hard-drive, but I kept getting an error message saying "File path too long". However the problem was that the drive letter assigned to the external drive wasn't the same I had configured in foobar library preferences. Once I changed it, it worked just fine.

So in short the "File path too long" message should have been something like "File not found" right?

I have everything working flawlessly with my 80GB Classic now, and I'm loving it . I have a couple requests however:

1. Would it be possible to "Refresh Album Art" so any new album art would be updated on the iPod. My issue right now is that finding better quality art and remaking custom art wont update already sent art on the iPod. Also, I find that if I send songs to the iPod WITHOUT art, and then "Sync iPod" when art has been added to the folder, the new art is NOT sent to the iPod.

2. Will images ever be supported so they can be sent to the iPod with foobar?

3. Is it possible to "Check For Updates" for iPod firmware with foobar, or is that only possible with iTunes?

4. I almost always get an error when trying to eject my iPod. I get "Failed to eject iPod. Close any applications using the device and try again.". I have no apple software running, and the ONLY thing related to the iPod seems to be foobar (which obviously needs to be open to eject). I don't know what's going on with that .

Quote from: blackspawn on 2008-04-28 12:14:47

Hello, I don't know if this qualifies as a "bug" (it's more a misleading error message). I was trying to send an album to my ipod from an external hard-drive, but I kept getting an error message saying "File path too long". However the problem was that the drive letter assigned to the external drive wasn't the same I had configured in foobar library preferences. Once I changed it, it worked just fine.

So in short the "File path too long" message should have been something like "File not found" right?

No. That error message should only trigger if the file is actually located on the iPod drive. The fact that it got past reading the iPod's database means it has the correct drive letter, as well. foo_dop doesn't care if the files are in your media library, or not.

So, I think the entries in your playlist probably pointed to paths that were on the external drive, but now on the iPod as the drive letter changed. I changed the driver letter of my iPod using disk management to W: and it has stuck since which helps avoid this kind of problem (Windows Vista here).

Musicmusic,

Would it be possible for you to make some variables to get the following information:

%ipod_size% = The size of the iPod (80 GB, 160 GB, etc)
%ipod_space_used% = The amount of GB used up on the iPod (returned in bytes)
%ipod_space_left% = The amount of space left for storage on the iPod (returned in bytes)

The variable codes can be different, those were just examples. I would find this information very useful for something I am making, and if you could implement this, that would be amazing .

Thanks for your hard work on this component .

Quote from: Keikonium on 2008-04-28 06:28:25

4. I almost always get an error when trying to eject my iPod. I get "Failed to eject iPod. Close any applications using the device and try again.". I have no apple software running, and the ONLY thing related to the iPod seems to be foobar (which obviously needs to be open to eject). I don't know what's going on with that .

4. Well, it could be some background application, you should see the same with "Safely remove hardware". I usually do a handle search with Process Explorer to find out what it is.

Sorry to bother you with this again Musicmusic, but I was just wondering if the following is ever going to happen: [...]

Often (not all of the time) when I add files to my iPod it lowers the amount of available space but the songs can't be found on the playlist... it seems like they're going into a neverland somewhere on the drive (5g Nano)

Also, any chance of adding an autofill function with the options of 1) delete and refill or 2) fill free space.  That would be great, especially 2 since Winamp can't do that.

The problem is that iTunes enjoys reloading the artwork when you use it - as I recall this is related to when it does its "determining gapless playback information..". As iTunes only sees the embedded artwork, the tracks without embedded artwork will lose their artwork. It should also leave the tracks with gapless data set by foo_dop alone. I cannot explain however why only some artwork formats are lost, that part of this behaviour is specific to the iPod touch / iPhone.

Regarding transparent artwork, this is known. I was hoping it was fixed in 0.5.8.8 TEST but if not I do not have a solution.

On the topic of artwork, I seem to have lost some of mine off my iPod also. I run an 80 GB iPod Classic, and since the newest firmware update (1.1.2) from Apple, I seem to have lost a bit of my artwork. It happened on random albums it seems, and foo_dop still says the artwork is ON the iPod (using the Browse iPod feature).

Would it be possible to have the option of whipping the artwork database, and resending artwork for all songs? I imagine it would be hard to find changes in artwork unless you used some kind of checksum or whatever to determine if the artwork has changed or not.

If this can't be done, I am just gonna erase my iPod (using iTunes) and resend everything with foo_dop again. I don't know what caused the artwork loss (probably the update?) but external artwork capabilities is one of the main reasons I enjoy using foo_dop .

So if I check "Disable automatic synching for all iPods and iPhones" - would iTunes stop doing that?

Your options are:
1. Embed artwork into all of your files, using tags that iTunes likes.
2. Only use files with gapless data (Lame MP3 / Nero AAC) and enable gapless scanning in foo_dop.
3. Keep iTunes in manual mode and avoid using it. It's possible to send videos using foo_dop, but you don't get the thumbnails (but you can manually create them like artwork). You can scrobble you plays to last.fm with foo_dop by using foo_audioscrobbler.

* foo_dop doesn't support any date added [to foobar2000 media library] field. The problems here are: Where do I get this from? foobar2000 doesn't track it automatically. Do I assume the user has set a metadata field for this? What is the name of the field? What format is it in? I guess I can workaround these problems as well, anyway.

I've noticed that foo_dop doesn't seem to check whether songs of the same artist/album/name already exist, such that it's perfectly possible to send stuff to the iPod that is already there without any sort of warning. Do you think it would be possible to implement some sort of measure to prevent/be informed of this in a future version?

On another matter, I have been noticing some odd conversion fails when sending tracks to the iPod from a lossless source. It sometimes happens when sending whole albums, that one or two tracks, usually the second and/or third last, fail to convert. Sending the failed tracks independently afterwards seems to work, so it's nothing wrong with the file itself. I am not sure if foo_dop is using multi-threaded conversion like foobar2000 itself does, as it's not obvious from its info box, but if that is the case and given the pattern, I have the hypothesis that it might fail whenever the last file in the set finishes converting before the second or third last do, or something along those lines. You might want to have a look at that.

Finally, I've also noticed that stopping any operation at the "Waiting for file info read to complete" stage renders foo_dop useless for any sort of operation with a "Cache read was aborted" error until one manually deletes the 0 KB metadata_cache.fpl file on the root folder of the iPod drive. Perhaps this is a potential problem you'd like to patch up in the future.