Can't play mp3s through 'Files' option (Sansa c200)

[pixelma]

Hmm, just saw MarcGuay's reply but I still think that auto-update could have an influene if it somehow alters the file(s) but I'm also confused about

Edit:  I've been playing around with trying to pinpoint this issue and it get stranger.  Its seems that the software will not recognize the files in the directory unless I do a manual update of the database (I have rockbox set to auto-update).  Even then, after an update, I have to reboot and if I try to play a file, the player will freeze and I have to take the battery out.  After doing another reboot, the files will play fine.

Are you playing the files through "File" browser (as the topic says) or "Database"?

As far as I know auto-updating the database is problematic on the Sansas and people were reporting a few issues (e.g. duplicate entries, too) - could you try without for a while? For example I don't use the database much and never auto-update only initialise again (I once tried a manual "update now" which didn't work correctly with plugged in and removing a microSD which is why I don't trust it).

I don't use even one of the two suspected features - it would really help if you could narrow the problem down with some experimentation and turning one or the other feature off and use it for a while. Hopefully you can find the problematic one.

[Lear]

One other thing to note, I am using auto-bookmarking and I have the database set to auto-update.

There are two parts to bookmarking, what happens on stop ("Bookmark on stop") and what happens on play ("Load last bookmark"). The way I read the above is that bookmarks are automatically created on stop, but nothing is said about what happens on play (which is the interesting bit in this case).

I tried setting "Load last bookmark" to yes in the simulator. Then stopped playback, creating a bookmark on the last file in the directory and renamed it. After that, when trying to play any file (of two) in the folder, there was some disk activity, and then nothing. Sounds very much like your problem...

Flashing the "Nothing to resume" message in this case sounds like a good idea. In fact, so good that I just committed that. Hope this fixes the problem.

[MarcGuay]

Hmm, just saw MarcGuay's reply but I still think that auto-update could have an influene if it somehow alters the file(s)...

Yeah doubt me all the way... I was just pointing out what I thought was the obvious truth, not something I know from digging through the code...

[krisdb]

There are two parts to bookmarking, what happens on stop ("Bookmark on stop") and what happens on play ("Load last bookmark"). The way I read the above is that bookmarks are automatically created on stop, but nothing is said about what happens on play (which is the interesting bit in this case).

Yes, I have bookmarks created on stop and I currently have it set to "load last bookmark".  However I had the same issue when I didn't have it set to "load last bookmark".

Now that I'm getting some decent feedback, I'm going to do another fresh install and recreate the problem.  I'm going to turn auto-update, "bookmark on stop" and "load last bookmark" off and see what happens.  I'm going to use the Sansa like I normally do, download mp3's into the /Music/Podcast directory, play them through the "File" browser (not "Database") and delete them from the Sansa directly.  If nothing happens, I will turn on each option until I recreate the issue.

Thanks for the feedback.

[pixelma]

Yeah doubt me all the way... I was just pointing out what I thought was the obvious truth, not something I know from digging through the code...

Apologies, I didn't mean to offend anyone, it's just that I distrust the database auto-update on devices with removeable media (my OndioFM with MMCs and the c200 with a microSD). As far as I know and was told by Slasheri this feature relied on dircache, which those devices don't have, to detect deleted files and this dependency was just removed recently and might still be buggy.

I just meant to have an eye on both (automatic bookmarking and the database auto-update). As I now realise my post wasn't very clear but I'm not a native speaker, was confused whether it's about database or file browsing, was almost finished with the reply when you posted yours and only followed my first notion that excluding this possibility was a bit too categorical, especially since bugs don't tend to be logical.

Nevermind if Lear's changes already clear things up and the problem is solved.

[MarcGuay]

Apologies, I didn't mean to offend anyone

You didn't offend me at all, I wasn't being sarcastic (for once)!  Sorry for the misunderstanding.  If it makes you feel any better even native English speakers have difficulty interpreting tone from words alone.

[krisdb]

Nevermind if Lear's changes already clear things up and the problem is solved.

I'm still testing it.  I've installed a fresh build and turned "bookmark on stop" off, "load last bookmark" off and auto-update off and am playing/deleting files through the "Files" browser like I normally would.  So far no issues, but I have a feeling once I start bookmarking/deleting, things are going to go haywire.  I'll let you know.

[krisdb]

Ok, I've been testing this issue out for the last week and I'm still getting the error.  I installed a fresh build, played mp3's through the File Brower, with all default settings, for a couple days and had no issues.  I then turned "bookmark on stop" on only.  That is when the weirdness started to happen.  When I powered down, I could see the "Bookmark Created" confirmation and when powering on I could see the bookmark under Recent Bookmarks, but when I manually selected it, to resume playback, it would just start at the beginning of the file.  I did this with a couple mp3s, with the same results.  I could still successfully click on any file (my original issue), under File Browser, but the file would never play from where the bookmark was created.  I then turned "Load Last Bookmark" on, and that's when my original issue was replicated.  After powering down, creating a bookmark, powering on, then trying to play the bookmark, I could no longer play any file, using the File Browser, and it would only flash the "Nothing to Resume" message.  So, here is a breakdown:

Default Settings
- no issues

Bookmark on Stop on
- file would not resume

Bookmark on Stop/Load Last Bookmark on
- file would not resume
- unable to play any file, in directory, using File Browser

The only thing I didn't turn on, during testing, was "Resume Playback" for the start screen, which I usually have on.

As far as I can tell, there something wonky with the bookmarking and play files through the File Browser, but my knowledge is limited.

Thanks for any help.

[Lear]

That is when the weirdness started to happen.  When I powered down, I could see the "Bookmark Created" confirmation and when powering on I could see the bookmark under Recent Bookmarks, but when I manually selected it, to resume playback, it would just start at the beginning of the file.

This sounds like a different problem, that I've heard happens on recent builds.

I then turned "Load Last Bookmark" on, and that's when my original issue was replicated.  After powering down, creating a bookmark, powering on, then trying to play the bookmark, I could no longer play any file, using the File Browser, and it would only flash the "Nothing to Resume" message.

Just making sure here... After enabling "Load Last Bookmark", did you delete any file before the problem started? Could you attach/PM me the full path to the folder, the name of all files in it, as well as the .bmark file for that folder? That could give some ideas on what is going on...

Regardless, the current behavior isn't very good. If "Load Last Bookmark" can't find the file to resume, it should play the selected file instead, I think. Setting "Load Last Bookmark" set to "Ask" would avoid this problem, by the way.

Bookmark on Stop on
- file would not resume

This should not happen with a build from Jan 18 or before...

[krisdb]

Just making sure here... After enabling "Load Last Bookmark", did you delete any file before the problem started? Could you attach/PM me the full path to the folder, the name of all files in it, as well as the .bmark file for that folder? That could give some ideas on what is going on...

I'm trying to think, but I don't think I deleted a file before creating the first bookmark and trying to load it, after turning "Load Last Bookmark" on.  I'm sure I turned "Load Last Bookmark" on, created a bookmark and tried to load it, before deleting a file.

I'll have to get you the .bmark file and folder path when I get to my home computer, since I don't have my USB cable with me.  It should be fairly easy to recreate it since I've probably done 4 fresh build installs and have been able to recreate the problem everytime.  Just load a bunch of mp3s into a directory under Music, play a file through the "File Browser", bookmark it, reboot and try to play the bookmark.  If that works, try bookmarking a file, deleting the file, play a different file and bookmark that one and try to load the new bookmark.  I'm trying to find a pattern to make it easier to debug, the closest I can get is trying this.

Edit: I attached my bookmark file (changed the extenstion to .txt so it will upload).  The full path to the folder is: L:\MUSIC\Podcasts.  I currently only have one file in there called 'wiik-in-review-12508.mp3', which does not resume when I try to play its bookmark and flashes "Nothing to Resume" when I click on it manually.

Edit2: This thing is so jacked.  So I only had the 'wiik-in-review-12508.mp3' file in the Podcast directory.  I just added two new mp3s, when I booted up my Sansa, instead of resuming 'wiik-in-review-12508.mp3' where I left off, it started to play one of the new mp3s.  When I tried to manually select the 'wiik-in-review-12508.mp3' file, the Sansa froze and I had to hold down the power button for 15s to reboot it.  When it hangs, it doesn't show any of the normal file info on the WPS. It shows (root) (root) 0:00/0:00 ?kBit (no id3), where the normal file information is displayed.  Rebooting once, allows me to play the 'wiik-in-review-12508.mp3' and I can move left and right to select the new mp3s, like it should.  If I try to go through the 'File Browser' to manually select an mp3, the Sansa hangs again and shows the WPS without the ID3 info.

[cdurst]

Could you try "downgrading" to r16099-20080118 and see if the bookmarking starts working again?

If so, perhaps this bug is the same one as reported in FS#8511(http://www.rockbox.org/tracker/task/8511).

[krisdb]

Could you try "downgrading" to r16099-20080118 and see if the bookmarking starts working again?

If so, perhaps this bug is the same one as reported in FS#8511(http://www.rockbox.org/tracker/task/8511).

Downgrading didn't work, but that bug looks a different than the one I'm experiencing.

[pokeme444]

tendinitis, can't tyupe much but
bug is killing me! some audiobooks affected, others not!
can't dig code, BUT

diff shows this function changed from

/trunk/apps/tree.c
/*    
     * removes the extension of filename (if it doesn't start with a .)    
     * puts the result in buffer    
     */    
    static char * strip_extension(char * filename, char * buffer)    
    {    
        int dotpos;    
        char * dot=strrchr(filename, '.');    
        if(dot!=0 && filename[0]!='.')    
        {    
            dotpos = dot-filename;    
            strncpy(buffer, filename, dotpos);    
            buffer[dotpos]='\0';    
            return(buffer);    
        }    
        else    
            return(filename);    
    }

to

trunk/apps/misc.c
 /*
1125           * removes the extension of filename (if it doesn't start with a .)
1126           * puts the result in buffer
1127           */
1128          char *strip_extension(const char *filename, char *buffer)
1129          {
1130              int dotpos;
1131              char *dot = strrchr(filename, '.');
1132              if (dot != 0 && filename[0] != '.')
1133              {
1134                  dotpos = dot - filename;
1135                  strncpy(buffer, filename, dotpos);
1136                  buffer[dotpos] = '\0';
1137              }
1138              else
1139                  strcpy(buffer, filename);
1140              return buffer;
1141          }



it seems a likely culprit for a subtle bug like this, especially with this code in the albumart;

http://svn.rockbox.org/viewvc.cgi/trunk/apps/recorder/albumart.c?r1=16102&r2=16103

someone could revert those changes and test whose hands work?

[GodEater]

I'd be pretty surprised if that's the problem - the code wasn't changed much (only two lines, and they're trivial), and was moved from one source file to another.

[Lear]

I'd be pretty surprised if that's the problem - the code wasn't changed much (only two lines, and they're trivial), and was moved from one source file to another.

Actually, that change can cause problems, though it isn't very likely to. With a file where the full path is more than 250 bytes (exact size depends on album art size), then the strip_extension call in albumart.c can cause a buffer overflow...

I intend to fix that, but I haven't gotten around to it yet.