foo_pod - Foobar2000 meets the iPod, iPod -> Foobar2000 0.8 Options

[clunesy]

Brushing the politics aside for a moment, I thought I'd get back to the actual business of discussing the plugin. Fantastic piece of software, it has restored my faith in 3rd party ipod loaders after the decline of Ephpod. I think I may have found a mini bug-ette anyhow.

It is said that Itunes is not required to use foo_pod, but I beg to differ slightly.
I am running itunes 4.8 and 60 Photo ipod with firmware 1.1 (23rd May release).
If I either load mp3s directly after a firmware reflash, or choose the rebuild database option, my ipod goes into a perpetual reboot cycle, showing the apple for a few seconds, clicking and showing it again.

The only way to get out of this, is by loading one mp3 in itunes before doing my main sync in foo_pod and by staying clear of the database rebuild ! I'm using 0.9.9j.

Anybody else seen this ?

regards

Niels

PS How / where do I post my itunesdb if anyone wants to see it
PPS Keep up the good work Aero. I think that bribery on the 0.9 could always be an option. What were the paypal details again .....

[Otto42]

clunesy: I suggest using iTunes to drop one mp3 file into the iPod Photo and send the resulting iTunesDB file to Aero. Clearly, the problem is in creation of a new iTunesDB file that the photo doesn't like, so figuring out what the deal is requires a known good file to see where the differences are between it and what foo_pod will generate for a new iTunesDB file.

[Aero]

Well seeing as people are pretty angry with what I said, let me clarify.  Firstly, I respect Aero greatly, as he has done a lot for the community.  His plugin is fantastic, and is one of the many reasons use foobar2000.  I am not angry that foo_pod (seemingly) is not going to be ported to 0.9, but with the reasons for Aero's decision not to.

The ban has very little with my decision not to port foo_pod to Foobar 0.9. I believe I alluded to the possibility of not porting foo_pod to 0.9 even before the ban.

Anyway, in order of priority, the reasons include:

1. Not having much time to work on foo_pod, in general.
2. No good reason (for me) to upgrade to Foobar 0.9.
3. The lack of a publically available SDK for 0.9.
4. Forum difficulties (i.e. the ban).


When Foobar 0.9 and SDK are released, if I find a good reason to upgrade and the 0.8->0.9 SDK changes are minimial, I might do the porting. But like I said, I really don't see any good reason to upgrade to Foobar 0.9 at this point, and several good reasons not to.

[Aero]

It is said that Itunes is not required to use foo_pod, but I beg to differ slightly.
I am running itunes 4.8 and 60 Photo ipod with firmware 1.1 (23rd May release).
If I either load mp3s directly after a firmware reflash, or choose the rebuild database option, my ipod goes into a perpetual reboot cycle, showing the apple for a few seconds, clicking and showing it again.

The only way to get out of this, is by loading one mp3 in itunes before doing my main sync in foo_pod and by staying clear of the database rebuild ! I'm using 0.9.9j.

Anybody else seen this ?

I have the same iPod and firmware, and I haven't seen any problems like that. In fact, I don't think I have ever used iTunes to load music onto my iPod (other than maybe to test database format changes and the ArtworkDB and Photo Databases).

Like Otto said, please send me your iTunes created iTunesDB along with a foo_pod generated one that seems to cause the reboot problem. If you can make them as small as possible (1 song, if that shows the problem), it would be helpful.

[musicmusic]

Hi Aero,
I have been having issue with recent versions of foo_pod. Bsaically when my ipod is connected, in foo_pod's menu "Eject ipod" is greyed out (and "Mount ipod" isn't). Clicking Mount ipod doesn't do anything helpful either.

Thanks.

[Aero]

I have been having issue with recent versions of foo_pod. Bsaically when my ipod is connected, in foo_pod's menu "Eject ipod" is greyed out (and "Mount ipod" isn't). Clicking Mount ipod doesn't do anything helpful either.

Nothing has changed with the mount/eject code in a while. I have seen this happen occassionally in the past, and it seems to be a problem with iPodService. Try restarting iPodService and see if that helps.

[drbeachboy]

I have been having issue with recent versions of foo_pod. Bsaically when my ipod is connected, in foo_pod's menu "Eject ipod" is greyed out (and "Mount ipod" isn't). Clicking Mount ipod doesn't do anything helpful either.

Nothing has changed with the mount/eject code in a while. I have seen this happen occassionally in the past, and it seems to be a problem with iPodService. Try restarting iPodService and see if that helps.

I had that same problem a few months back, and re-installing iPodService was what corrected it for me.

[musicmusic]

I have been having issue with recent versions of foo_pod. Bsaically when my ipod is connected, in foo_pod's menu "Eject ipod" is greyed out (and "Mount ipod" isn't). Clicking Mount ipod doesn't do anything helpful either.

Nothing has changed with the mount/eject code in a while. I have seen this happen occassionally in the past, and it seems to be a problem with iPodService. Try restarting iPodService and see if that helps.

Well, it works ok with foo_pod 0.8. I have had this problem for a while (and it always happens, it doesn't only happen occasionally).

The other problem I have had is that after a 'Sync All Playlists' you seem to keep a handle open to the "Ipod_Control/iTunes/Play Counts" file, which also renders the "Safely remove hardware" feature of Windows useless for ejecting the ipod until I close foobar2000.

This post has been edited by musicmusic: Jun 22 2005, 21:00

[Aero]

Nothing has changed with the mount/eject code in a while.  I have seen this happen occassionally in the past, and it seems to be a problem with iPodService.  Try restarting iPodService and see if that helps.

Well, it works ok with foo_pod 0.8. I have had this problem for a while (and it always happens, it doesn't only happen occasionally).

The mount/eject code hasn't been touched since well before v0.8, so there must be something else going wrong. And really the only thing that can go wrong is iPodService. Make sure you have the latest version installed.

The other problem I have had is that after a 'Sync All Playlists' you seem to keep a handle open to the "Ipod_Control/iTunes/Play Counts" file, which also renders the "Safely remove hardware" feature of Windows useless for ejecting the ipod until I close foobar2000.

This is a bug, but it can only occur if the Play Counts file is unreadable by foo_pod. Try deleting it and see if the problem persists.

Edit: Actually, before you delete it, send me the Play Counts file so I can figure out why foo_pod can't ready it.

This post has been edited by Aero: Jun 22 2005, 22:47

[musicmusic]

Nothing has changed with the mount/eject code in a while.  I have seen this happen occassionally in the past, and it seems to be a problem with iPodService.  Try restarting iPodService and see if that helps.

Well, it works ok with foo_pod 0.8. I have had this problem for a while (and it always happens, it doesn't only happen occasionally).

The mount/eject code hasn't been touched since well before v0.8, so there must be something else going wrong. And really the only thing that can go wrong is iPodService. Make sure you have the latest version installed.

I have iPodService version 11 according to foo_pod. Probably not the latest, no; I will try downloading a newer version of ipod updater.

And yes, foo_pod 0.8 is working ok. I would guess something to do with ipodservice has changed on your side (broke compatibility with old version ?) because the ipodservice tab in prefs is not filled in with 0.9.9j but it is with 0.8.

[edit]
Alas, this is probably the change that broke it for my old ipodservice

Version 0.9.5 - December 5, 2004
*  Fixed an incompatability with recent versions of iPodService, which caused the Mount/Eject functions to not
  work correctly.

Mystery solved...

I would suggest if you don't want to support old versions of ipodservice you should handle it more elegantly..

The other problem I have had is that after a 'Sync All Playlists' you seem to keep a handle open to the "Ipod_Control/iTunes/Play Counts" file, which also renders the "Safely remove hardware" feature of Windows useless for ejecting the ipod until I close foobar2000.

This is a bug, but it can only occur if the Play Counts file is unreadable by foo_pod. Try deleting it and see if the problem persists.

Edit: Actually, before you delete it, send me the Play Counts file so I can figure out why foo_pod can't ready it.

It is zero bytes big.

This post has been edited by musicmusic: Jun 23 2005, 00:03

[Canar]

I've just tried using this component for the first time. I was rather unimpressed.

On top of locking the main window whenever it accesses my iPod, it takes an eternity to do so, often giving no dialog box informing me anything is happening, and so on.

It refused to put any music onto my iPod (sometimes even claiming to have successfully done so), through transcoding or copying, until I switched to Disk mode. Even then, when transcoding large amounts, it locked my foobar and prevented me from even pausing the currently-playing track. So, I had a single second or two interval of a track stuck repeating for quite some time.

I think I've finally got it working decently now, but it still likes to lock foobar and prevent me from using it at all while it does things, which is enormously frustrating. I'm probably going to ditch it soon and go back to a transcode -> iTunes format after the current transcode finishes. At least then I can use foobar2000 while it's transcoding.

This post has been edited by Canar: Jun 25 2005, 08:18

[ReD-BaRoN]

Questions on the pre-amp stuff.

From what I can tell by exporting the iTunesDB, the pre-amp stuff that foo_pod does increases the volume variable in the DB. This results in the song playing louder when the iPod volume is turned to 50% for example, than a song which has not had the pre-amp applied. The problem with this, however, is that the iPod volume maxes out depending on how much preamp was applied.

For example, if I preamp a song (with soundcheck data) to 100%, any volume adjustments on the iPod past half-way make no difference, I'm assuming that the song volume variable plus iPod volume has past some threshold. Without sound check data this doesn't happen. Basically, there seems to be some max volume that I'm hitting when using soundcheck, and the greater the pre-amp by foo_pod, the quicker I hit that max on the iPod volume adjustment. (e.g. a preamp of 100%, I get no increase in volume past half-way, a pre-amp of 50% I get no increase in volume past 75% of the volume slider).

What I like to see done, if possible, is to rather than adjust the volume variable of the song, is to actually decrease the db reduction of the soundcheck.

Basically, soundchecked songs don't get loud enough for me, and when using the existing preamp, I'm hitting some volume limit on the iPod (not this isn't a Euro iPod). Again, when I'm not using SoundCheck this limit is not an issue (it get's way loud).

Aero, does this make sense? Is it doable?

Thanks!

[Aero]

I've just tried using this component for the first time. I was rather unimpressed.

Wow - that's a great story. Thanks for sharing! Hope you have better luck with something else.

[Aero]

From what I can tell by exporting the iTunesDB, the pre-amp stuff that foo_pod does increases the volume variable in the DB.  This results in the song playing louder when the iPod volume is turned to 50% for example, than a song which has not had the pre-amp applied.  The problem with this, however, is that the iPod volume maxes out depending on how much preamp was applied.

I'm sure the iPod has some sort of internal limiter, to prevent the amplifer from being overdriven.

What I like to see done, if possible, is to rather than adjust the volume variable of the song, is to actually decrease the db reduction of the soundcheck.

Basically, soundchecked songs don't get loud enough for me, and when using the existing preamp, I'm hitting some volume limit on the iPod (not this isn't a Euro iPod).  Again, when I'm not using SoundCheck this limit is not an issue (it get's way loud).

Aero, does this make sense?  Is it doable?

You are adjusting the pre-amp setting for both SoundCheck and non-SoundCheck songs, right? Semi-recent versions of foo_pod have separate settings for songs with and without SoundCheck, although I believe some iPod firmware versions ignore the volume/pre-amp setting when SoundCheck information is present (which is likely your problem).

I suppose I could add some sort of SoundCheck bias setting, but you could also manually adjust the ReplayGain values on your songs and make them a little higher - say take a -6dB RG value and make it -3dB or 0dB. What I will probably do is remove the slider for RG pre-amp (since it doesn't always work, depending on the firmware version) and replace it with a Quieter/No change/Louder switch that would do what you are looking for. I'll consider putting that in the next version.

[Mike Giacomelli]

I've just tried using this component for the first time. I was rather unimpressed.

Wow - that's a great story. Thanks for sharing! Hope you have better luck with something else.

One question though, why does foo_pod (and many other plugins) tend to lag or freeze the main window while they run? Is this a foobar threading limitation?

[Aero]

One question though, why does foo_pod (and many other plugins) tend to lag or freeze the main window while they run?  Is this a foobar threading limitation?

foo_pod had been like that since the beginning, then I experimented with allowing Foobar access during foo_pod operations. Unfortunately, there were a bunch of unexplained crashes around this time as well, so I reverted back to the much-loved way.

I'm not really sure if the problem is something I'm (not) doing, or if it is a Foobar problem. At the risk of being banned again , Foobar has some limitations with respect to multi-threaded components. So I think the problem could be something internal to Foobar, but it is hard enough to track down that I have just gone for the easy solution and locking down Foobar during foo_pod operations.

[Canar]

Wow - that's a great story.  Thanks for sharing!  Hope you have better luck with something else.

Maybe you missed the point. In its current form, I'm personally pushing to have foo_pod added to the Problematic list. Components should never lock foobar2000 like foo_pod does, preventing cancellation, playback, and interaction with the main window for an extended period of time.

If you're having issues with writing proper multithreaded code, drop by #foobar2000 on Freenode. I'm sure they'll help out if asked nicely.

This post has been edited by Canar: Jun 26 2005, 06:50

[Skates]

Wow - that's a great story.  Thanks for sharing!  Hope you have better luck with something else.

Maybe you missed the point. In its current form, I'm personally pushing to have foo_pod added to the Problematic list. Components should never lock foobar2000 like foo_pod does, preventing cancellation, playback, and interaction with the main window for an extended period of time.

If you're having issues with writing proper multithreaded code, drop by #foobar2000 on Freenode. I'm sure they'll help out if asked nicely.

Problematic list? Get real, the component works fine and has worked fine for many...

[kl33per]

Whilst I do find it annoying that foobar's not accessible whilst foo_pod's working, adding it to the problematic list is over-the-top and will likely only discourage Aero further from working on this project. The problematic list is for plugins that have really big problems (the ever present example of incomplete unicode support), or crashes a lot. Not having foo_pod multi-threaded, whilst annoying, is not a serious problem and/or flaw, and certainly doesn't cause damage to foobar's configuration or any of your music files. It's just the way it is.

[drbeachboy]

Wow - that's a great story.  Thanks for sharing!  Hope you have better luck with something else.

Maybe you missed the point. In its current form, I'm personally pushing to have foo_pod added to the Problematic list. Components should never lock foobar2000 like foo_pod does, preventing cancellation, playback, and interaction with the main window for an extended period of time.

If you're having issues with writing proper multithreaded code, drop by #foobar2000 on Freenode. I'm sure they'll help out if asked nicely.

You know Canar, maybe you missed the point! Had you not been so smug in your original post, you may have received a better response than the one that was given. So, don't act like a child, go run and tell mommy because you got your feelings hurt. Aero has been very responsive at upgrading foo_pod when we post here with problems. Aero deserves to be treated with respect, as do all the members here in this forum. Try it Canar, you just might like it!

Regards,
Dirk

[hedge153]

Whilst I do find it annoying that foobar's not accessible whilst foo_pod's working, adding it to the problematic list is over-the-top and will likely only discourage Aero further from working on this project.  The problematic list is for plugins that have really big problems (the ever present example of incomplete unicode support), or crashes a lot.  Not having foo_pod multi-threaded, whilst annoying, is not a serious problem and/or flaw, and certainly doesn't cause damage to foobar's configuration or any of your music files.  It's just the way it is.

Yeah agree totally, Aero, you do a great job with foo_pod, and its much appreciated by many many users of foobar. It has always worked as close to flawlessly as is humanly possible for me, and the VERY minor irritance of locking up whilst sending to an ipod is hardly worth mentioning. Start some music you like to listen to on before you start a transfer, send your files (which won't take all that long anyway), whats the prob?

I must say though, I am a little disappointed with your decision to not update to .9, but at this stage 0.8.3 does everything (and more due to all the unported extensions) that i'll ever need for quite some time to come.

[foosion]

At the risk of being banned again  , Foobar has some limitations with respect to multi-threaded components.

There are some APIs that may only be called from the main thread, and they are clearly marked as such. I don't know why talking about this in a factual manner would result in any kind of punishment.

In its current form, I'm personally pushing to have foo_pod added to the Problematic list. Components should never lock foobar2000 like foo_pod does, preventing cancellation, playback, and interaction with the main window for an extended period of time.

Bugs and crashes are reasons to put components on the list of known problematic components, not unliked but completely legal behaviour. We will not label a component as problematic on such grounds.

[Canar]

Bugs and crashes are reasons to put components on the list of known problematic components, not unliked but completely legal behaviour. We will not label a component as problematic on such grounds.

So locking foobar2000 for an hour and a half while the same 2 second loop of music played, preventing me from cancelling the operation or even stopping playback so I could do something else with my soundcard while it operated is considered "legal behaviour"? If the plugin had actually done something useful after that time, I might even be able to agree. However, it returned a console literally full of error messages that I was unable to see and stop so I could fix the problem.

However, I suppose that'd be at best merely my opinion. Hmm.

Edit: For the record, I was using foo_pod to put MPCs on my iPod, so it was transcoding. I can recreate the lockup easily by doing precisely that.

This post has been edited by Canar: Jun 26 2005, 21:46

[Canar]

Whilst I do find it annoying that foobar's not accessible whilst foo_pod's working, adding it to the problematic list is over-the-top and will likely only discourage Aero further from working on this project.  The problematic list is for plugins that have really big problems (the ever present example of incomplete unicode support), or crashes a lot.  Not having foo_pod multi-threaded, whilst annoying, is not a serious problem and/or flaw, and certainly doesn't cause damage to foobar's configuration or any of your music files.  It's just the way it is.

I see your point here, but personally disagree. Foosion (and the other devs I mentioned this to) seem to agree more with you than me, so I'll let my last post stand and see how this plays out.

This post has been edited by Canar: Jun 26 2005, 20:39

[foosion]

The problem described by Canar seems to indicate that foo_pod lock the metadb for a longer period. While this is not strictly illegal, it is not very cooperative either and should best be avoided. My advise would be to check the code for this and either lock the metadb once to retrieve all necessary information at the beginning or to lock it for each file separatly. Feel free to ask questions regarding the SDK in the dev forum or on IRC.