PhatNoiseProgrammer

I know programmers hate suggestions. I know, I designed and programmed media players, including the PhatNoise PhatBox and the Harman/Kardon Drive + Play 2. So, apologies in advance for complaining about all the hard work you've already put in. I know you're working off a fairly new code base after shifting from iMX series to OMAP and Embedded Windows to QNX. I'm going to guess a lot has been re-done from scratch - something painfully obvious with all the iPod iAP crashes - I never saw that in 5 years of use with the exact same iPod with ~6000 songs on Sync 1 (2012 Focus, 2015 Explorer). There's got to be some new code in there. I've been playing with it for just a handful of hours, here's what I'm seeing, with USB. Sync 3 with SW 2.2. All songs just dumped over from iTunes, all MP4 tags, all ALAC. NOT using Gracenote management (out of principle - I remember the day they privatized and started charging for CDDB content...) 1) Album name browsing is not dropping "A" and "The" in the sort, so "A Music Album" is sorting before "Awesome Music", instead of between "Make Music" and "My Music" Not sure if you are trying to read a sort order from the tag or not. This is a bit annoying. Is it my problem in that I need to clean up the tags, or have you just not implemented cutting the articles? 2) When using voice to select a new song / album / etc., when the entire exchange finishes and Sync confirms the new selection, we still hear a short clip of the previously playing song. Somewhere in the code, when the voice prompt ends, you are resuming audio playback (which had been paused), and *then* you are changing the index to play the next thing. Fairly jarring depending on what was playing previously. I'd suggest taking a look at that sequence to see if you can add a bit more logic. I've seen the counter example, which is when I tell sync to play what's already playing (while playing album "Foo" on track 1, I tell it to play album "Foo" and it confirms and just picks up right from where it was - no track restart or anything). I'd gladly give that up if you made sure the playback index changes before the prompt ends so that when playback resumes, it's on the new track, not the old track. 3) Album Art. Ugh. I hear this is a mess right now, with gracenote always showing no matter what. This is silly, please fix. I have 6000 songs with years of correctly embedded Album Art, including stuff that just isn't on gracenote (it's a custom recording with my own artwork, etc.). 4) You have some odd things going on for icons in the scrolling - i've seen a few albums showing up for a little bit as "song" icons, then reverting back to "album" icons, and while file system browsing, saw folders without the folder icon at all, but then it showed up after scrolling away and then back. Not sure what that's all about. I will keep looking to see if I can find the reasoning on this. 5) Off-by-one somewhere on track listings. I think on the flat track list, I saw an off-by-one error. the song that was playing was not highlighted, and instead the next song was highlighted. This happened while I was looking for a song via the alpha browse. Strange also, the screen kept scrolling by itself, slowly. Will try to replicate. 6) Home screen metadata - This one drives me nuts, and it's a big divide for media management and metadata displays, but it's a huge annoyance for people who have stuff that's not artist-focused. Some people care about the name of the song and the name of the artist. But other people care about the name of the song and the name of the *album*, especially when on things like soundtracks, classical, etc. The artist could often be some random orchestra somewhere that did the recording. What's more useful in that case is the name of the album (e.g."Overature"/ "Der Fliegende Hollander" instead "Overature"/"James Morris;Deborah Voigt;Ben Heppner" who are the three "artists" on that track). Please make it a choice as to that secondary piece of metadata after the track name. 7) Index file - this one just seems like you could really save a lot of headaches if you would provide a method to create the index file offline, and store it on the media. You could easily do a hash on the filesystem structure / modification times to make sure the offline created index is valid (I suspect you do that now to trigger the re-indexing). If you issued an indexing script (or even just the format of the index), and then grabbed an index from the media if present, you could avoid all the "it's taking forever to index" problems. Please?

I want to clarify something in the original poster's instructions. While it is organizationally useful to have a "Music" and "Playlists" structure, it's not necessary. The files can be organized, or not. What's critical is that any m3u files have the right paths. See the images from this test flash stick. Note that there are three albums, two of which are in the drive root, and one in a subfolder, and the m3u file for the playlist "Export_Test.m3u" is also in the root. See inside the subfolder (The Abyss) Next, see the m3u file, and note that the m3u file was in the root of the stick (this M3U was exported from a playlist created in iTunes, and was exported to m3u format, then edited to strip the path down to just the file path on the USB stick): In fact, I originally had all music in the root, then moved the one album into a subfolder and edited the m3u file to reflect the change. I suspect that all the sub-folders are actually not ideal, for two reasons: A file system indexing routine needs to essentially do a recursive search through every folder hierarchy, starting at root, to look for folders and files. Every one of these is a file system read, and then holding an index or memory structure of the directory listings, and popping back out to go dive through the next one. There's the file system (e.g. flash stick) read speed issue, and an overall system memory usage. Having everything flat definitely gets rid of all the recursion and additional file system reads. Also will cut down on the size of the index file, as long path names don't need to be stored. Excessive path lengths may cause problems in the indexing to search via Metadata and voice. I've already found a weird merging of two albums into a single interleaved album (15 tracks + 23 tracks, showing 38 tracks, with track 1, then 1, then 2, then 2, etc.) and the key thing is both are Star Wars films (ep 3 and ep 7). But playing them directly via album browse is fine. I'll guess something is getting borked in the index and generation of voice prompts, especially since I get a query back from voice command for which line # - but it's "Episode III" and "Episode 3" - but I've never tagged anything "Episode 3" (just the "III") Just a final note - it's odd having done in vehicle media playback before iPods even existed at PhatNoise, having gone through all of this before. I'm a little surprised at how a lot of the same issues keep coming up, now 15 years later... sigh. I just started using Sync 3, and just switched to USB flash from iPod (160GB) due the crashing issues (usually due to iAP out-of-bounds issues!). I was previously on a Sync 1 with that iPod, and prior to that, a Harman/Kardon Drive + Play 2 (a product I designed). Seems like a lot of things are still difficult to get right.