Yeah, same crash with 0.5.2. I'm using xp pro as well.

Since I have been unable to reproduce the crash, I prepared a debug version of foo_pod 0.5.2 to help narrow down the cause.

If you are experiencing the crash while writing the iTunesDB file and would like to help, please download foo_pod_debug.zip and try to reproduce the crash. This version of foo_pod writes some debug information to c:\foo_pod.txt, so after the crash, either post or PM me that file.

Thanks!

Thanks for your persistance in trying to solve this issue. With the debug version I got the same error, and one line was written in the foo_pod.txt:

From debug version:

12309189: iTunes.bak --> 'F:\Program Files\foobar2000\\iTunesDB.bak'

4100295: iTunes.bak --> 'E:\Program Files\foobar2000\\iTunesDB.bak'

Wow that sounds great - Exactly what I was hoping for.

Thanks Aero...

pnjman & dragonfin: Thanks! Interesting...that isn't where I expected it would fail. If you (or anyone one else) wouldn't mind, please test out foo_pod_debug2.zip. There is a chance that it might fix the crash, but if not, it will provide more detailed information about what is going wrong.

Using the debug2 version foobar now crashes as soon as I select send file to ipod.

From log:

12309189: iTunes.bak --> 'F:\Program Files\foobar2000\\iTunesDB.bak'
13797029: Writing iTunesDB file
13797029: iTunesDB --> 'g:\iPod_Control\iTunes\iTunesDB'
13797029: iTunes.bak --> 'F:\Program Files\foobar2000\iTunesDB.bak'

Crashed again.

5343293: Writing iTunesDB file
5343293: iTunesDB --> 'j:\iPod_Control\iTunes\iTunesDB'
5343293: iTunes.bak --> 'E:\Program Files\foobar2000\iTunesDB.bak'

Thanks again! I'm getting closer, and seem to have to problem narrowed down to one function. I have one more version to test - foo_pod_debug3.zip..

Again, there is a chance that this will fix the crash, but it definitely will narrow down the problem if it doesn't fix it.

Using debug3 it's still crashing as soon as I select send file.

From log:

15246663: Writing iTunesDB file
15246663: iTunesDB --> 'g:\iPod_Control\iTunes\iTunesDB'
15246663: iTunes.bak --> 'F:\Program Files\foobar2000\iTunesDB.bak'
15246663: Populating default playlist
15246663: Populating now
15246663: Populating done

foo_pod_debug4.zip

Last one for awhile, I promise. This will narrow the crash down to a single line of code.

Debug 4 works great. My ipod can play all my asian songs now! Awesome!

Sucsses!!!!!!!!!!! It works. Thank you.

Cool! I didn't want to sound like a broken record, but I was hoping that #4 would be the lucky build.

Unfortunately, I'm not totally sure why what I changed suddenly stopped working in 0.5.1. I'll need to examine that further, but since it looks good, I'll remove the debug stuff and release it as 0.5.3.

Version 0.5.4 is now available.

This version actually does fix the crash reported in 0.5.1 and 0.5.2. Thanks again to dragonfin, pnjman, and somasatellite for putting up with the bug and all of the debug builds to figure out exactly what was wrong!

Edit: I was able to determine why 0.5.1 and 0.5.2 were crashing, and found a similar piece of code that could crash in the same way. I have no evidence that such a crash will occur, but since the other bug was so tedious to track down, I decided to fix the problem and release 0.5.4. If you have 0.5.3, you probably should upgrade just in case.

Thank you, Aero. Great work!

Looks good. Glad you guys nailed it!

Wonderful community!

take a look at mlipod (or ml_ipod cant remember the exact name) on sourceforge, or gtkpod. lots of code you may wanna see

Thanks for the pointers - I hadn't heard about mlipod before.

gtkpod is, AFAICT, just a C++ version of the Perl scripts in GnuPod. From what I have read, it is probably the 2nd most complete iPod library implementation (behind Otto's iPodDB).

Except for mlipod, I have looked at nearly every open source iPod library out there, and Otto's is by far and away the cleanest and best code out there. Most of the others are obvioulsly hacked together, and lack the basic understanding of the complete iTunesDB file.

For example, I found a Winamp 5 plugin the other day, and I was curious about what, if any, features I could implement (read: steal ) from it. Actually, it is called ml_ipod.dll, but I it isn't the same code as the above link, or it was based on an earlier version. So I was browsing through the code, and it was clear that it was, quite simply, crap. This one line of code from ml_ipod.dll sums up my impression:


Not only is the code completely wrong, but when you see comments like that, you know that it was written by some snot nosed 15 year old hacker (in the worst sense of the word).

Anyway, I'll get off my soap box now, but the main point is that iPodDB rulez, and there is little, if anything, that any of the other projects could add to it.

I have looked at them all. I've got well over a dozen source codes that are all supposed to read or write the iPod's files. I drew my beginning knowledge of the iTunesDB file from them.

However, I've experimented and tested and worked at getting all the details down much better than any of those projects. I can easily state that the iPodDB classes I wrote, and which Aero has hugely helped me to refine with usage, are far more capable than any other freely available code out there for writing and reading the iTunesDB file format. Only iTunes has more capability, and that's only because they know what all the fields mean.

Okay, so the iPodDB classes lack a bit of ease of use functionality, but then you can easily wrap them in something if you want simple to work with. It's not necessary to do so, but it can be done easily enough.

The only thing I'm lacking that anybody else has is smart playlist functionality, (gtkpod, I think? I don't recall offhand). But that's only because I want to do a better and more complete job. The one I looked at was.. well.. a bit of a hack job. It didn't define it very well, for certain. I can reverse engineer the thing from files produced by iTunes easily enough, but it's a PITA, and frankly I've not had time to do it properly yet.

Actually, I know the guy who wrote it, heh. He's actually a decent programmer, though I haven't seen his code. I dunno.

I'm sure he is a great guy and I don't mean to pick on him, but I can't understand why someone would put something like that out for public distribution. Especially these days, where your entire online history is just a Google search away. Every time I start a contract or do an interview, the client either comes right out and says they have googled my past work or you know they have based on their questions. I'd hate to be this guy going into an interview in 5 years and have someone bring this code up.

Anyway, we're totally off topic now. Getting back to foo_pod, I've started working on transcoding support, so FLAC/OGG/WMA/etc. files will be able to be transparently transcoded to MP3 or AAC, and sent to the iPod. I'm also working on the one last major performance issue.

I personally got rid of that line of code, and now the internationalisation support for ml_ipod is as good as the rest of winamp (that is, if your windows code page is set correctly, you can view text in your languages charset perfectly).

(I won't comment on you calling Christophe a 15 year old snot nosed hacker. Save to say that I totally disagree with you).

Will Fisher

Umm, well I may have written the comment (Though I think a friend wrote the actual code), I forget, but I appreciate your concern for my image, but the reality is that I'm not planning on going to interview for a job anytime soon, and if I was, I would simply explain that that comment was to explain that that code was sub-par and lacking, and that I am very capable of using the word that twice twice in a row in a sentence, without causing real issue. Thanks, Justin.

Aero:

You've been SERVED.

-Christophe

That's lovely. It was a fairly sophomoric line of code and surely makes it harder to take your project seriously. Possibly you can prove the community wrong and help out with foo_pod. More collective knowledge is always good.

Well, now that everyone has had their say and I have been SERVED, I suggest we get back to foo_pod discussions...

Actually, it is a wonderful allusion to a recent episode of South Park.

Very cool plug-in, Aero! Thanks a lot!! I'd like to add that this plug-in was the reason I finally went out and bought an iPod. This is the best iTunes replacement... EVER!!!

I've only got one thing, though...

I can't seem to play songs that have characters like:

(Nelly Furtado) Força
(Gyllene Tider) Det Är Över Nu

As far as I can tell from the changelog, this should be corrected by version 0.5.1 with character escaping? Or is that only for strictly non-european characters (as ç, ä and ö are european characters... )?

Other than that, thanks for a plug-in that just makes foobar that much better...

Thank you for your kind words!

You should try foo_pod version 0.5.4 and see if that fixes your problem.

The situation is that the iPod doesn't handle certain filenames, which as you have experienced, includes filenames with some non-English characters. So even though foo_pod was handling them correctly, I had to add the filename espcaing to allow the songs to be played on the iPod.

dragonfin reported that 0.5.4 filename escaping fixed the problem with Asian character containing filenames, so I would expect that it would also fix European filenames as well, but if it doesn't, send me the filename(s) that don't work and I'll see about adjusting the escaping algorithm.

Thanks for the quick reply!

I can tell you, that every day I get home from work, I check to see if you've made a new version... which means I've already tried 0.5.4... and it doesn't work...

Anyways, here are some examples of characters that don't work:

ç, ä, ö, å

Those are the only ones I've tested. I would suspect that the danish characters æ and ø don't work either...

You don't need the whole filename, do you? If so, I can just post them...

Thanks again!

No, I can create some test cases with those characters and see if I can reproduce the problem. I'll try to test it out tonight.

Maybe I should ask Christophe and friends for their solution...

Edit:I actually looked, and they work around the filename problem by duplicating what gtkpod does and copy songs to the iPod with a dummy filename (e.g. ml_ipod12345.mp3). That is definitely the easiest solution, but I was hoping to keep as much of the original filename as possible.

Maybe I should escape the filenames down to straight ASCII (no non-English characters), but add a metadata tag to the file with the original, unmolested filename? That way, with the right program (like a future version of foo_pod), you could copy files off of the iPod and retreive the correct filenames.

That's odd, because on my ipod i've found that some of those characters work. Björk works fine, as does the æ in Sigur Ros's Agætis Byrjun. Though I haven't tried these in foo_pod yet, these were loaded months ago with ephpod. Though Aero mentioned that it doesn't have to do with foo_pod, but rather with the ipod itself. I'm using a 10gig gen. 2 ipod.

Ephpod is probably doing filename espcaing, and you just didn't notice since you normally don't see filenames on the iPod.

I posted this above as an Edit, but I think what I'm going to do is convert all filenames to straight ASCII or do what gtkpod/mli_pod are doing, but include a metadata tag in the file on the iPod which contains the original filename. That way, it will be possible to copy the files off of the iPod and retreive the correct filename.

Note I do not own an Ipod, but a small suggestion comes to mind, don't know if it's possible to do, but here goes:

In filename, replace the ç, ä, ö, å with c, a, o, a respectively, while keeping the id3 tag (because Ipod use those, right?) intact with ç, ä, ö, å letters? Can Ipod display those? If so, problem seems solved to me?

Oh, and I didn't read the whole thread before posting this, so flame me if this has already been suggested.

That is a good idea, but it is a little more complicated than that. For example, what if you have 2 songs: â.mp3 and ä.mp3. If you just strip off the accent, you would end up with duplicate filenames (which isn't necessarily an error, but it could be depending on the situation). And I can't even begin to think how to escape non-Latin characters, like Hebrew, Arabic, or Asian glyphs!

What I am currently doing is just randomly picking a character and inserting that in place of the non-ASCII character. Another solution would be to use URI style escaping such as %3f , or simply just not using the original filenames at all.

Oh no, it's a good idea... I'm just inclined to think like Aero; it would be rather cool if you could keep the original filename intact. If you can't, tough luck, but, you know... it's just one of those things...

By the way... I myself have tested Sigur Rós... doesn't work either...

Actually, the iPod can't even show the letter ý in Ný Batteri!! I haven't seen that before!!

Actually, this idea is preatty good - my Thomson portable works with this idea, as you can transfer any filename with any accented characters (latinic letters only, I think) and it displays them converted to the defult english alphabet - the original filename does not change when viewed e.g. in Total Commander. So it's kind of an intelligent behaviour on the side of the player, sad that iPod does not do this.

Aero, maybe you could append a number at the end of the converted filenames - so e.g. "Kispál és a borz - Szívrablás" would be "Kispal es a borz - Szivrablas - 1" or something, and the next track with the same name could be "Kispal ... - 2". This way the name could be preserved.

The example is in Hungarian, in case you were wondering.

edit: added some clarification

The problem is that while is easy for a human to look at "á" and see that it should be translated to "a", it is hard for a computer to do so. I'm sure there are probably libraries available that can do the translation (if anyone knows of a good one written in C or C++, please point me to it), but this is getting pretty complicated for a device that theoretically doesn't even care about filenames.

I am going focus on getting something working, first of all, so everyone can play their songs on the iPod. Then I'll see about making it nice.

May be the best thing to do is to just hash out any unusuable characters, as I'm pretty sure everyone will have the correct info in the tags if they are planning to use the files on an iPod.

The only problem would be if you wanted to copy the files from the iPod to the PC, but this could be gotten round by renaming the files based on the tags.

Just my 2 cents.

Yep, you're right, but you know the string for a filename, and you can parse it, right? So if you get to a character which is of a not supported character code, you simply look up in a character table you created to see what you have to write instead of the not supported character. Let's see some pseudo-code (maybe java style, you'll surely get it)


I hope this is about right and makes sense But this is possible to make! As my mp3 discman uses some similar algorythm.

Actually, you could replace the letters with their sound - as I am Swedish, I can contribute some; å would then be "aa", ä would be "ae" and ö would be "oe". Ofcourse this requires that every language that has those special characters "chip in" to the mix. For example; french's "ça va?" would be "sa va?" instead - practical renaming still maintaining the "meaning" of the sentence/word. Ofcourse this creates even more problems (if there is any such cases) with characters that have multiple sounds depending on the word. If not, be happy

But then again, I'm not capable of coding this. I just try to come up with some sort of solution - I have no idea how easy/hard this is to actually do, code-wise.

Dumb question, maybe, but what does iTunes do with these files? Does it rename them when transferring to the iPod? I know it normally does not rename files, but if they don't work, then they don't work, and we should try to emulate the operation of iTunes in this respect, methinks.

D'oh, why didn't I think of that before???

iTunes replaces all "foreign" characters with an underscore (_).

That's propably the easy way around it...

Thanks for all of the suggestions, but this is getting way too complicated.

My best ideas so far are to:

1. Just replace the non-ASCII characters with random letters. This is quick and easy, and it doesn't change the length of the filename which would be important if the filename just barely fit into the allowed space (255 characters or less). The downside is that it ruins the filename so that there is no chance to recover it, without adding metadata to the file itself.

2. Encode the UTF-8 filename with URI style escaping (e.g. %3f). This is nice because the filename itself contains all of the information necessary to recover the original filename. The downside is that most European characters require 2 UTF-8 bytes + the "%", and Asian characters can be upto 4 bytes total (3 UTF-8 bytes + "%"). That really cuts down the maximum filename size.

3. Get rid of filenames altogether, and use the gtkpod solution. This is the easiest of all, but I don't think anyone wants an iPod full of foopod12345.mp3 files, at least without an easy way to convert them back to the original filename.


Otto42: iTunes does some heavy filename escaping, so even legal filenames are changed. And its goal is different - I'm trying for the best way to preserve the original filename, while iTunes doesn't care since it doesn't allow the user to copy files off of the iPod anyway.

Basically, the problem is that there is no really good way to work around the iPod's filename limitations. Like I said earlier, I'm going try to make it work for all character types, then see if it is worthwhile to make it nice.

I love you Aero, you're so sexy

I'd very much like to second that!

You have obviously heard the stories about the size of my pod...