android
  #601  
Old 12-06-2013, 02:36 PM
Carson Dyle Carson Dyle is offline
Member
 
Join Date: Nov 2010
Posts: 285
Default

Quote:
Originally Posted by skip252 View Post
If you place the playlists on the external memory all the files from both the internal and external memories will be recognized. It's been like that since saratoga reworked the code quite a while back. I don't think the manual has been updated to reflect all the changes to the Playlist Catalog since the major rework a couple of years ago so that may also be a part of your confusion.
Are you saying playlists must be located on the card in order to be able to reference files located in the internal memory, or are you saying that file paths within the playlists are automatically fixed up when the playlist are located there?
Reply With Quote

Advertisement [Remove Advertisement]

  #602  
Old 12-06-2013, 03:45 PM
skip252 skip252 is offline
Administrator
 
Join Date: Dec 2007
Location: Chicago
Posts: 5,442
Default

You can't sync the list from the now playing pane. That copies the files again as you've seen. Exporting it as an external playlist won't cause any files to transfer. I find it fairly simple now that I've got it set up.

I drag the files I want into the now playing pane, arrange them the way I want and export them as an external playlist to the location I've chosen as the playlist catalog. I set the Playlist Catalog folder location in the MusicBee library preferences as the save location for exported .m3u lists.

To make sure MusicBee always exports playlists to the right location and can recognize them again I've assigned drive letters permanently to all my Rockboxed players and cards. In Windows you can do that in the Control panel under Administrative Tools, Disk Management. When I first started I used "R" and "S" as they weren't in use and easy to remember. It's worked well so I assign them to any players and card I use.

The nice part about that is it allows me to keep all of them in sync. External programs won't overwrite the files as long as I keep the same folder\file structure as it always sees the same drives whichever player I use. If a file isn't there the software reads the drive, it sees what's missing and adds it.

There no software I know that's able to see what's on one drive, compare it to the other and add the missing files to the correct drive. I've seen a few posts that have used different files sync software and a one that used a really complicated MediaMonkey script but they seemed like too much effort for too little return.

I just load a few hundred of my absolute favorites on the main memory and have a card large enough to hold the rest. I'm never going to be able to put a significant portion of my collection on any currently available device so I don't worry about using all the memory.

The file paths are fixed for use in Rockbox when you store the playlist on the external memory using software or making them on the player. Playlist that are made or resaved by Rockbox on the player won't be read by external software. The addition of <microSD1> on AMSv2 players like the Clip and original Fuze breaks the file paths for external software. <MMC1>does the same thing on the Fuze+.

The oddest part is that the rework by done to the Playlist Catalog and how saving to the external memory fixes the file paths doesn't seem to have made it into the manual. One of the most confusing part of Rockbox was made leaps and bounds easier and more functional and as far as I can tell no one has documented it. Damn shame, it's just so much better now.
Reply With Quote

  #603  
Old 12-06-2013, 10:29 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,644
Default

Quote:
Originally Posted by Carson Dyle View Post
Are you saying playlists must be located on the card in order to be able to reference files located in the internal memory, or are you saying that file paths within the playlists are automatically fixed up when the playlist are located there?
Basically, when you provide a playlist its usually ambiguous which volume is referenced because of how MSC mode works. I changed the logic so that if its ambiguous the player will assume you mean the same disk as the playlist is stored on.

If you make each playlist so that the paths are explicit (e.g. /<microsd1>/path/to/file) then it will work no matter what. If its ambiguous (e.g. C:\myfiles\file.mp3), it'll guess that "C" is whatever disk the playlist is currently stored on.
__________________
Interested in Google's Summer of Code ? PM me.
Reply With Quote

  #604  
Old 09-27-2014, 05:52 PM
lebellium's Avatar
lebellium lebellium is offline
Samsung Moderator
 
Join Date: Sep 2007
Location: Paris
Posts: 3,614
Default

Some interesting news here:
http://forums.rockbox.org/index.php/topic,48549.0.html

Zip never dies
__________________
I'm French^^ *GenerationMP3 Samsung Moderator*
Reply With Quote

  #605  
Old 09-28-2014, 12:39 PM
skip252 skip252 is offline
Administrator
 
Join Date: Dec 2007
Location: Chicago
Posts: 5,442
Default

Don't know if it's the KnK build\theme or the applied patches but it's definitely a WIP.

I tried the posted build using -V5 MP3files and the results weren't good. When I tried M4A files at ~128 kbps the results were worse. I noticed the author of these patches says they're testing using FLAC files. I tried using FLAC files and the results were borderline but acceptable.

With FLAC files navigation would lag some but continued to function. With both MP3 and M4A navigation would eventually lock up and I needed to reset the player to regain control.

I don't use any DSP settings I consider exotic but lags and lockups during menu navigation when I applied them using any files other than FLAC were consistent. The same tweaks I use in the Bass and Treble setting along with a single band in the equalizer being active causes it it to slow down and eventually lock up. When I used the EQ with 3 bands active without the Bass and Treble settings it locked up even faster.

The disk activity icon is on more than off. Not sure how it works but it seems that having the disk being read that much would use more battery than what the other settings would save. It isn't consistent but I notice that loud pops occur in close proximity of the disk read activity the light indicates.

Playback also stops and starts when the screen finally changes after a menu navigation or screen change lag with a fairly loud pop. The pop is often enough that I have to wonder if it's putting my headphones at risk. The pop isn't very loud on boot but it's loud enough on shutdown that I disconnect my headphones before before turning it off. It's really loud then. The shutdown pop happened with all the files I tried.
Reply With Quote

  #606  
Old 09-28-2014, 01:56 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,644
Default

The max clock in that patch is probably too low for anything but flac. I'm not going to commit that as is, but I am interested in his experiments in how clock speed changes power consumption.

Previously we explored dynamically adjusting the clock speed, but found that it had little improvement in battery life. If there is a way to reduce power consumption by lowering some combination of clocks when the CPU is idle, we can try again.
__________________
Interested in Google's Summer of Code ? PM me.
Reply With Quote

  #607  
Old 09-28-2014, 03:40 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,644
Default

I committed the safer 2 patches which just disable more unused hardware. On the clip zip they increase battery life by one third. On the plus the impact hasn't been tested but may be nearly as big.
__________________
Interested in Google's Summer of Code ? PM me.
Reply With Quote

  #608  
Old 09-28-2014, 06:35 PM
skip252 skip252 is offline
Administrator
 
Join Date: Dec 2007
Location: Chicago
Posts: 5,442
Default

I installed a dev build with the patches you committed, f014a76-140928. Performance and sound are what I've experienced with previous builds. No lags, freezes or pops.

I'll get it fully charged and run before and after battery benches. The batteries in the ones I have are fairly old but doing tests on the same DAP will give me an idea of the relative difference.
Reply With Quote

  #609  
Old 09-28-2014, 06:42 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,644
Default

Do you have a clip+ to test with? I'd be interested in the relative difference there.

Mine is also charging, but I don't have a baseline to compare with so it'll take me a few days to get numbers.
__________________
Interested in Google's Summer of Code ? PM me.
Reply With Quote

  #610  
Old 09-28-2014, 09:30 PM
skip252 skip252 is offline
Administrator
 
Join Date: Dec 2007
Location: Chicago
Posts: 5,442
Default

I do but I'm not setup to build Rockbox. Post a link to any builds you want me to bench and I'll get started as soon as they're fully charged.
Reply With Quote

  #611  
Old 09-28-2014, 09:31 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,644
Default

Quote:
Originally Posted by skip252 View Post
I do but I'm not setup to build Rockbox. Post a link to any builds you want me to bench and I'll get started as soon as they're fully charged.
Just the current build vs. one from anytime before today.

Edit: http://download.rockbox.org/daily/sa...s-20140927.zip

(A build from yesterday if you haven't already done a battery bench in the last year).
__________________
Interested in Google's Summer of Code ? PM me.
Reply With Quote

  #612  
Old 09-29-2014, 12:31 PM
skip252 skip252 is offline
Administrator
 
Join Date: Dec 2007
Location: Chicago
Posts: 5,442
Default

Here's what I get using 515a3c5. I used the same set of -V2 LAME mp3 in both cases. I had a set of stock buds attached to each to listen for when playback stopped. I'm recharging to do it again with a current build.
Attached Files
File Type: txt Clip+ version 515a3c5.txt (36.8 KB, 12 views)
File Type: txt ClipZip version 515a3c5.txt (46.9 KB, 11 views)
Reply With Quote

  #613  
Old 09-29-2014, 01:23 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,644
Default

I get (on Zip):

Last spring: 10h 14min
Current git: 13h 35min
Current git + 1.1v CPU: 15h 0min
__________________
Interested in Google's Summer of Code ? PM me.
Reply With Quote

  #614  
Old 09-30-2014, 12:42 AM
Mikerman Mikerman is offline
Ultra Senior Member
 
Join Date: Dec 2007
Posts: 2,543
Default

Now, that's a nice bump indeed!
Reply With Quote

  #615  
Old 09-30-2014, 07:31 AM
skip252 skip252 is offline
Administrator
 
Join Date: Dec 2007
Location: Chicago
Posts: 5,442
Default

Here's the result with 7c20d8f. There's a healthy jump in runtime. It went from 11:38 hrs to 15:50 on the ClipZip and from 09:04 hrs to 13:55 on the Clip+.

The near 5 hour jump on the Clip+ just doesn't seem right. The battery in that Clip+ is fairly old but I expected better than 9 hours. I'm running that again using 515a3c5 to see if the results are consistent.
Attached Files
File Type: txt ClipZip version 7c20d8f.txt (109.5 KB, 14 views)
File Type: txt Clip+ version 7c20d8f.txt (55.7 KB, 6 views)
Reply With Quote

  #616  
Old 09-30-2014, 08:37 PM
skip252 skip252 is offline
Administrator
 
Join Date: Dec 2007
Location: Chicago
Posts: 5,442
Default

Fortunately I had saved the entire 515a3c5-.rockbox folder that I used for the battery bench that resulted in the 9 hour 5 minute runtime. The volume had been set at -1 instead of the default -25. I had pushed the volume rocker when I braced my thumb on it to remove the USB cable and hadn't checked again when I started the test.

I ran another battery bench with all the settings on the defaults and the runtime came out at 10 hrs 27 mins. The difference between that and the 13 hours and 55 minutes using the 7c20d8f build that has the committed patches isn't as great but still a significant improvement.

You said the increase was even greater with the current git plus a 1.1v CPU increase. Is that something you're looking at committing or are there drawbacks that won't let that happen?

EDIT: Just in case someone see these battery bench result in the future. The Clip+ I used is somewhere ~3 years older than the Clip Zip. That means the battery is that much older and has seen hundreds more charge\discharge cycles. That means that it doesn't hold a charge as well as the newer Clip Zip. That's the reason for the differences in runtime. Not that the Clip Zip natively has better battery life or that Rockbox works better on the Clip Zip.
Attached Files
File Type: txt Clip+515a3c5-default volume.txt (42.3 KB, 5 views)

Last edited by skip252; 09-30-2014 at 09:09 PM. Reason: Added more info on the age differences of the players tested
Reply With Quote

  #617  
Old 10-01-2014, 10:28 AM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,644
Default

I actually got exactly the same battery life on my clip+, which seems wrong. I'm going to do some more tests and probably a historical comparison.

I'm not sure about the lower voltage. My player doesn't even boot at 1.0v, and while it runs fine at 1.1v, I'm not sure about everyone. If frequency scaling goes in, lowering the voltage at low clock speeds would make sense.
__________________
Interested in Google's Summer of Code ? PM me.
Reply With Quote

  #618  
Old 10-02-2014, 10:48 AM
skip252 skip252 is offline
Administrator
 
Join Date: Dec 2007
Location: Chicago
Posts: 5,442
Default

Ran another with 515a3c5 on the Clip+. Thee results are consistent with the one I didn't screw up. There's a ~13 min difference, 10:39 vs. 10:26 but that's close enough to call them the same in my book.

I've got another running now on the Clip+ with the dev build that has the committed patches. If that's consistent with the first run I'm thinking that the patches are a worth keeping as I'm not experiencing any freezes or pops like I'm getting with the last custom build the author of the patches posted.
Attached Files
File Type: txt Clip+515a3c5-default volume 2.txt (42.9 KB, 3 views)
Reply With Quote

  #619  
Old 10-03-2014, 10:27 AM
skip252 skip252 is offline
Administrator
 
Join Date: Dec 2007
Location: Chicago
Posts: 5,442
Default

I get 13:23 with the second run of the dev build 7c20d8f that has the committed patches. That's not quite as good as the 13:55 I got on the first run but still enough of a difference to say that there's an improvement in runtime.
Attached Files
File Type: txt Clip+ version 7c20d8f_2.txt (53.6 KB, 1 views)
Reply With Quote

  #620  
Old 10-10-2014, 05:44 PM
lebellium's Avatar
lebellium lebellium is offline
Samsung Moderator
 
Join Date: Sep 2007
Location: Paris
Posts: 3,614
Default

Thanks for sharing your results skip252 and saratoga! Here are mines:

4'30 MP3 VBR V0 file (~283kbps) - Repeat One - volume -35dB - screen turned on for 20 seconds ~5 times - my lebellium Samsung-like theme

Clip+ (more than 4 years old):
- 32a6ed8-131213: 10h13min
- 877bd98-141008: 12h36min

Clip Zip (3 years old):
- d188661-140702: 11h35min
- 1e7b93a-141009: 15h53min !!
__________________
I'm French^^ *GenerationMP3 Samsung Moderator*
Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



All times are GMT -5. The time now is 09:22 AM.