Rockbox Technical Forums
Third Party => Repairing and Upgrading Rockbox Capable Players => Topic started by: RockBoxNewB on September 25, 2016, 11:40:04 AM
-
Hi everybody,
Rockbox has been my faithful companion for a couple of years now, I couldn't imagine my iPod 7G 160GB without it anymore.
Unfortunately, hard drive space is getting smaller and smaller, and I decided to get myself an older iPod Video 5G with 30GB built in, so I can mod it with an iFlash Quad microSD adapter. Modding worked, and I have successfully upgraded it to something around 350GB of storage. Using RockBox on these advices seemed to be common practice, so that's what I did...but I was disappointed to see that it just doesn't work as it should.
There are some issues that I can at least find a workaround for... but the fact that playback is often interrupted by skips and that the iPod becomes unresponsive at times are just things I cannot get along with in the long haul. After having these issues, I read some of the other posts, stating that RockBox, in general, seems to work poorly with these adapters.
Is this really a hopeless case, or is there anything underway that might improve RB support on those devices? If not, there is really no way for me but to get rid of that thing again, since without RB, it is basically worthless for me.
Any feedback or ideas would be very much appreciated!
RBNB
-
I assume you've read this thread?
http://forums.rockbox.org/index.php/topic,51460.0.html
Edit - though 350gb on an originally-30gb ipod (i.e. 32mb ram model) is a bit of a stretch - doesn't give you much on-board RAM for coping with the large database you may have if you are using that much storage. Could still work with rockbox, but the trouble is the original firmware might have problems, which would in turn cause problems with syncing in OF mode.
Basically, try (re) synching your library using drag-n-drop in OF mode, but it might be that you need to start with a 60gb or 80gb model if you want to make full use of 350gb. Though, on reflection, it will probably work, just that negotiating menus and building the database might be very slow and choppy.
-
HI Frankenpod!
For some reason, although I read through all threads all the way back to 2014 in this sub-section of the forum, I did not see that one! Thanks for that hint.
I also asked around in the Rockbox IRC channel, and the people there also kept pointing me towards RB's USB handler which seems to cause problem with these iFlash adapters. I figured that as well, I already noticed that the only way to transfer all my files is using Apple's OF for the procedure. Otherwise, transfers would get cancelled with a "data loss during write" error.
Unfortunately, even after transferring everything per drag-and-drop from the OF, I still get those skips. Not only from large FLAC files, but also standard mp3s.
Right now, my only hope is an iPod with more RAM - although that means I can basically throw away my iPod 5G. Well, I guess this is the cost of experimentation :-D
If anybody else has an idea or experienced the same thing, I would still highly appreciate any feedback!
Thanks,
RBNB
-
The amount of ram won't make any difference for rockbox. You need an ad adapter that is compatible with out Atat driver, or to hack our ata driver to do what your adapter expects.
-
As you say its a 'quad adaptor' I assume that means it's Tarkan's, as I don't know of another quad adaptor. I have had no problems with other Tarkan adaptors (haven't used the quad), at least when using the OF to transfer files.
Though I have found some brands of cards really don't like Rockbox. So it could possibly be the card brand you are using, I guess.
As far as RAM is concerned, I can only say I've found rockbox performs much more reliably (if using the database feature), on ipods with more RAM. It doesn't freak-out completely as soon as you have too many tracks the way the OF does, but it really seemed more likely to freeze while switching menus and much more prone to require multiple attempts to build the database. Possibly if you don't use the database feature at all it wouldn't be an issue.
-
The database uses the same (tiny) amount of ram on 32 and 64 MB iPods, so I dont think it should affect it either way.
-
Thanks saratoga and Frankenpod for your insightful and quick answers, your help is very much appreciated!
Right now, I'm a bit at a loss what I should try next... or what I should try at all. And yes, you are right - I purchased one of Tarkan Akdam's iFlash Quads, I am also not aware of any alternative products in this category.
For storage, I use one SanDisk Ultra 128GB as well as two Samsung Evo+ 128GB micro SDs. From what I read on Tarkan's page, all of these are confirmed to work with the adapter! I COULD try to switch them around (at the moment, the SanDisk is in slot 1, but I could put one of the Samsungs there...however, I'm not sure if this will work easily since the entire storage structure might be wrong then).
You could say I was putting all my hope into the attempt to modify a later iPod with more RAM - but your answers suggest this is not going to improve things radically. That puts me back to square one.
Going without the database is no option for me in the first place. From other threads, I understood not too much attention is put on this feature and it seems that not many use it. For me, it's essential though! At the moment, I have a collection of around 7500 songs, and the main feature for me to sort them is by RATING. Yes, you read right. For several years now, I have rated each and every song I put on my RockBox device. That's still how it works best for me, as silly as it might sound to some. Without the database feature, all of that would be impossible.
After all, I'm not sure if the database itself is the reason for my problem. I did not have time to test properly whether using RockBox but deactivating the database changes anything. But as I said, without the database, the device is without value for me.
Similarly, using only the original Apple firmware is out of question. I need the massive file format compatibility of RockBox, particularly for FLAC files since almost my entire collection consists of those.
As far as the USB issue goes... I would not mind having to boot into Apple FW everytime I transfer files to the iPod, as long as that would help. I need to do that anyway, since all file transfers fail via the RockBox USB handler anway. This also worries me a lot, because I HAVE already transferred all files via the Apple firmware, so according to what you say, there shouldn't be any issues anymore! Or do you mean I have to transfer everything via ITUNES? What I have done so far is start the Apple OF, connect USB but still use drag-and-drop via Windows Explorer to send the files over.
I hope this clears up some things! Please let me know what your guesses are.
Best,
RBNB
-
The only thing I can say is that I have found some brands of full size SD cards don't like Rockbox on ipod Classics even if they work with OF. Don't know if that is even relevant to ipod videos (which I think deal with the drive differently?) or to micro SD cards.
I don't suggest transferring via iTunes, what you have done is what I do and it works for me.
Are you saying the thing works if you ignore rockbox completely and do everything with iTunes/OF? If you only have flacs I would assume you can't even test that, so maybe there's something else wrong and its not actually to do with rockbox? (i.e. bad usb cable, bad drive cable or drive cable not fully inserted in iflash, faulty card, card not formatted the right way, etc?)
You could also remove some cards, reformat and start again, and see if either the samsung or the sandisk card works on its own in slot one.
(If you rearrange or remove cards you will have to completely restore and start again)
(If one brand doesn't work I'd be interested to know as I might get a quad adaptor myself some time!)
-
Thanks saratoga and Frankenpod for your insightful and quick answers, your help is very much appreciated!
Right now, I'm a bit at a loss what I should try next... or what I should try at all.
Its pretty clear given the constant stream of people posting with problems that these adapters do not work with rockbox. Unless you're intending to add support for whatever they need to the ATA driver, you can try using the Apple firmware.
-
I have to concur with saratoga here regarding RAM.
Even on the 32MB iPod Videos an overwhelming percentage of RAM is left over for the audio buffer. The amount used by the database is truly insignificant. You can view this yourself very easily in the debug menu. Throwing more RAM at this when we already have plenty to spare won't solve anything.
On the iPod Videos I would be far far far more willing to believe that the bottleneck is either disk or CPU based (CPU on the iPod Videos is less than stellar, three or four bands in the parametric EQ and you're going to have trouble with real-time decode of lossy formats), or plain observational bias.
I'm not too willing to think the latter without experimentation though, since the fancy new filesystem code no one actually needed ended up nuking database-in-RAM capabilities because it "wasn't needed" and "should be fast enough", something that I am not even going to pretend I'm not bitter about.
If someone gets adventurous and wants to beat me to the punch comparing database performance (with both database-in-RAM enabled and disabled on the legacy build, preferably) with git head vs. 95a4c3a (just before the WIP filesystem rework) that would be neat.
[Saint]
-
Once again, I'm really happy about the great feedback you three guys provided, which allows me to look at the problem from very different viewpoints. And by the way... you brought back the spirit of experimentation in me :-)
I wasn't able to grab hold of a newer iPod anyway, so I decided to go back to the basics and try to re-build my iPod 5G from the ground up. I started by taking out all 3 microSD cards. In the meantime, I had ordered a 200GB SanDisk Ultra (yes, I know, megalomania calling). I decided to put just this one single card inside the iFlash Quad, leaving the other three slots empty for now. I wanted to cover 2 cases in one, because if this helped, I could limit the reasons to either the iPod being too slow to handle more than one card simultaneously OR it just not liking one (or all) of the cards I used so far.
Since a complete restore was required now anyway (like one of you mentioned), I could also make sure that all files are transferred through Apple's OF.
For now, I only found the time to test it with a sample of 10 files (no lossless ones, though). Even after activating the database, there were no hiccups or skips after about 10 minutes of testing. If my plans work, I will do the real testing tomorrow, once again transferring my entire collection over and also trying to import the database which I built up in recent years. My hopes are back that this might work in the end. 200GB are no 384, but it's still better than nothing and will buy me another couple of months before space runs out!
@[Saint]: By the way, if there's any chance you can provide a build for the 5G which still includes the LOAD-TO-RAM feature (just like you did for my iPod Classic, which was a revelation), that would be very much appreciated! I'd love to test its performance on my particular device.
Best,
RBNB
-
I could also make sure that all files are transferred through Apple's OF.
Do you mean disk mode (https://support.apple.com/en-us/HT201544#ipod-click-wheel) or just an USB connection when running the OF?
-
What I meant was just a USB connection when running the Apple OF - I haven't tried disk mode to be honest. I actually don't think that this is what causes the problem... the data transfer itself seems to be fine like this. The skips don't seem to occur at specific points but rather randomly.
By the way, in my experiment with the 200GB SanDisk Ultra, I did NOT format the drive prior to inserting it into the iFlash Quad. It was bought new, I took it out of the packaging and inserted right into the adapter. I don't know if this makes ANY difference, but the three 128GB cards were formatted to FAT32 first.
Right now, I am transferring my whole collection over to the iPod. I have made another short test - it still seemed to work, but at some point the iPod would become unresponsive again, right from the System menu where I could not remember having pressed any buttons... it "woke up" again after a couple of minutes, so this should not mean anything for now.
When all music is transferred, my first test will be to play through some tracks, still only using the standard RockBox theme, NO equalizers or any additional options activated, and the database also remaining turned off.
If that should work, I will try to activate additional options one by one and check when the iPod starts to get into trouble again.
As always, if you've got any ideas, just let me know!
RBNB
-
As an aside, whether you formatted the micro SD card or not doesn't really matter at all if you then do a complete restore of the original firmware, which itself will setup the storage to its preference (FAT32 on Windows based machines and HFS+ for Macs). As long as you're going to do a complete restore it doesn't really matter what the format of the storage is beforehand, it doesn't even need to have any partitions or a partition table.
Basically a long winded way of saying that as long as you're doing a restore of the original firmware, anything goes as long as the hardware and software have a path to the raw storage that they can agree on.
[Saint]
-
Hi guys,
let me give you another status update on how things are going.
After my first simple tests went well, I then went one (or maybe even two) steps further and activated my favorite theme as well as the database. Except for one situation where my iPod was stuck in one of the menus, still no trouble. After that, I copied my database over from my other iPod (7000+ entries) and used the "import modifications" option. This caused quite a number of hiccups. The first three times, "FAILED" was displayed and it didn't work. I have no clue what the problem was there...I re-initialized and rebooted a couple of times, and the third time was the charm! Phew. The import procedure took something between 2 and 3 hours (!!!) and drained the battery down to 30% again. Around 70 entries seem not to have been imported unfortunately... but considering the almost 7000 that HAVE been imported properly (as far as I can judge), I think this is a good bargain.
Since then, I have been using the iPod for a little more than one hour - and there have been NO skips at all! Touch wood.
From what I described, does anyone of you have an idea what the problem might have been in the first place? Is it the fact that I used just ONE big micro SD card as compared to three "smaller" ones? Would not seem to make sense to buy an iFlash Quad then, if you get nothing but problems when you use all slots...
By the way: which files do I need to copy between devices in order to import the database? Does the "changelog" suffice or do I also need one of the other files labeled "database..."?
Thanks once again,
RBNB
-
By the way, I forgot to ask again: for the time being, RockBox seems to be running better than ever, particularly as far as its general response time goes. But once again, there's one thing I am still mourning about: LOAD TO RAM. My personal habits involve a heavy use of the database feature, and whenever RB has to go back to a list of songs within the database, it takes a long time to load (even smaller lists). The battery drain is also heavy because of this. I could imagine that just like on my other, "still-HDD-based" iPod, load to RAM could help excellently with both these issues.
Sorry to annoy you with this, but: Is there any way somebody could supply a pre-filesystem-rework build with LOAD TO RAM still included?
Thanks in advance,
RBNB
-
By the way: which files do I need to copy between devices in order to import the database? Does the "changelog" suffice or do I also need one of the other files labeled "database..."?
I don't know if it is possible to transfer the database from one device to an other, but the files labelled database_*.tcd contain the database. As long as the file structure is the same on both devices, copying those files could import the database.
Is there any way somebody could supply a pre-filesystem-rework build with LOAD TO RAM still included?
If you use such a build, you will not have all the new features and bugfixes that were committed since then.
Better than waiting for someone to supply such a build is making your own. I recently made myself familiar with compiling and stuff, it is sometimes not easy, but so great if you manage to compile your own build. This is also more in line with "hacking" and "modding" like you do it with your iPod. So I suggest to have a look at http://www.rockbox.org/wiki/DevelopmentGuide and http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling
If you have Problems, there are many helpful people here who you can ask.
I hope you achieve what you want and enjoy your rockboxed and modded iPod.
Edit: Didn't [Saint] provide you with such a build? (http://forums.rockbox.org/index.php/topic,51191.msg236396.html#msg236396)
-
Hi,
Starting with your last point first: [Saint] provided me with a build compiled to include load to RAM - but that one was for my other iPod, a 6G 160 GB model. Not knowing better, I even tried that build in the first place - but it lead to an error on my 5G model which then refused to start RockBox after all. I assume both models are completely incompatible in that respect...
I have copied over the RockBox database between devices several times (or let's say: I attempted to do so). Sometimes it worked, sometimes it didn't. I think migrating it between different manufacturers is something I haven't managed to do so far (I think this concerned both moving from a Sansa Clip Plus to a Cowon i5 as well as moving from the Cowon to the iPod). Moving between iPods worked so far, except for some hiccups and partial loss of database information.
I took a look at some links on compiling. Although I might know my way around stuff better than I did some years ago, I'm afraid that skill-wise, I'm VERY far from successfully compiling my own build. I assume I'd rather brick my iPod a dozen times than actually being able to make it work, I guess!
Best,
RBNB
-
By the way: which files do I need to copy between devices in order to import the database? Does the "changelog" suffice or do I also need one of the other files labeled "database..."?
I don't know if it is possible to transfer the database from one device to an other, but the files labelled database_*.tcd contain the database. As long as the file structure is the same on both devices, copying those files could import the database.
Don't do this.
The Database context menu has export and import options for precisely this purpose, this exports to an ASCII plain text file that guarantees forward and backward compatibility.
Is there any way somebody could supply a pre-filesystem-rework build with LOAD TO RAM still included?
If you use such a build, you will not have all the new features and bugfixes that were committed since then.
Better than waiting for someone to supply such a build is making your own. I recently made myself familiar with compiling and stuff, it is sometimes not easy, but so great if you manage to compile your own build. This is also more in line with "hacking" and "modding" like you do it with your iPod. So I suggest to have a look at http://www.rockbox.org/wiki/DevelopmentGuide and http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling
I'm going to go ahead and guess you're not familiar with the massive complexity surrounding the filesystem rework, and that's fine. I don't expect you to.
If this was a simple change I would have done it a couple of years ago. If this user wanted to retain the current feature set and bugfixes, you're looking at multiple tens of man hours work for an experienced embedded developer, likely hundreds for an inexperienced one, and borderline impossible for Joe Everyday,
This is significantly more involved that just tracking down a single (or even a couple of) commit(s) and reverting it(|them). The idea of cleanly reverting the current code base to the legacy filesystem code and keeping the feature set and bugfixes added since then is basically an idea that isn't worth entertaining. The change touched hundreds of files in thousands of locations, and because of its very low level interaction, pretty much every non-trivial change or addition since then is directly or indirectly tied to these changes.
Not least of all is that this is only really interesting for testing purposes, we're only interested in if performance has indeed degraded, and if so by how much. We don't need to bring a legacy function up to the current code base in order to test this.
If it turns out that there is a significant performance hit, there's basically two options going forward:
- completely revert the filesystem rework and then rebase ~75% of all the commits added since (....Not gonna happen. Period. You can take that to the bank).
- re-implement an analog to the 'cache in RAM' feature against the modern filesystem and core (Waaaaaaaaaaaaaaaaaaaayyyyyyyy less work, but still non-trivial, and not an area of the code base that I am at all comfortable or familiar with. The Database function and its interaction with the filesystem has remained largely untouched for years because it is made of prayers, good intentions, bailing twine, and magic).
[Saint]
-
Hi [Saint],
Thanks for your once again "enlightening" insights.By the way: which files do I need to copy between devices in order to import the database? Does the "changelog" suffice or do I also need one of the other files labeled "database..."?
I don't know if it is possible to transfer the database from one device to an other, but the files labelled database_*.tcd contain the database. As long as the file structure is the same on both devices, copying those files could import the database.
Don't do this.
The Database context menu has export and import options for precisely this purpose, this exports to an ASCII plain text file that guarantees forward and backward compatibility.
What I was asking (more or less) is: is the database_changelog the ASCII plain text file you were talking about? Because using the import/export options from the menu is exactly what I did, I was just wondering whether it is just the changelog file which I need to copy to the other device for import?! When I did that, it worked after all, but with the hiccups I mentioned, more precisely some dozens of files not receiving the info which was actually already stored in the database.
To be honest, what you say about compiling is pretty much what I expected. It would have surprised me A LOT if I was able to get up to speed quickly to indeed create my own build for the iPod. This makes me even more overwhelmed about how you managed to compile the build for my other iPod 6G that included Load-to-RAM. I assume this is not possible for the 5G Video?
As an alternative (although, I know, you don't recommend it), is it possible to get just the old build with Load-to-RAM, without the bug fixes made since? Without anyone having to compile or modify anything, just the plain build that was available before the filesystem rework? I searched around a bit, but I could only find builds that are max. a couple of months old.
Best,
RBNB
-
Is there any way somebody could supply a pre-filesystem-rework build with LOAD TO RAM still included?
If you use such a build, you will not have all the new features and bugfixes that were committed since then.
Better than waiting for someone to supply such a build is making your own. I recently made myself familiar with compiling and stuff, it is sometimes not easy, but so great if you manage to compile your own build. This is also more in line with "hacking" and "modding" like you do it with your iPod. So I suggest to have a look at http://www.rockbox.org/wiki/DevelopmentGuide and http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling
I'm going to go ahead and guess you're not familiar with the massive complexity surrounding the filesystem rework, and that's fine. I don't expect you to.
You are right, I can not imagine what it means to develop or write code for such a complex thing as the filesystem, I didn't suggest to rewrite the code, but I tried to encourage the OP to learn how to compile a pre-filesystem-rework build on his own. Thanks to the great documentation, this should be feasible for an advanced computer user within a few days.
-
Alright guys, considering that my computer knowledge won't be "advanced enough" to compile a build myself, I tried another way to solve the problem - or rather: go around it. the 5G iPod Video with extended flash storage was actually only planned as a "pilot project" of sorts. I wanted to test the procedure before I modify my 6G iPod Classic 80GB (and possibly brick it in the process). I decided to do this know because I felt confident enough not to damage the device, and because I considered it interesting to see how RockBox runs on a device with more RAM and a better processor.
The installation worked without considerable problems. Unfortunately, the 6G iPods have a 128GB limitation within iTunes, so it would not show the full 384GB of storage (this time I used the three 128GB micro SDs again). It is possible to "unlock" the full capacity using Rockbox - but this also means that it is no more possible to use the "safe file transfer" procedure by booting into the Apple OF before connecting USB. Anyway, I was able to transfer all files without the connection crashing and as far as I could judge from a short test, there seemed to be no skips during playback or anything.
But then - the database again. As opposed to the 5G iPod Video, until now, I have NOT been able to successfully transfer the database to this iPod. This would be a major dealbreaker for me. The following happens, and I have never had that so far with all the different database transfers between devices which I have done so far: After transferring the database_changelog.txt from the old device over to the 6G iPod, I hit "Import modifications" from the database menu. As usual, the screen freezes, displaying "Loading". This time, however, it would never awake again. For some minutes, it is possible to turn screen backlight on by pushing any button, where you can still see that it is "loading". After some minutes, however, the iPod would stop reacting to anything. Backlight cannot be reactivated, and it also cannot be turned on by pushing "Play". This could suggest that the device is somehow still turned on. The only way to get it back to life is to do a hard reset by holding "Menu" and "select". I have given it around 30 minutes time so far, the situation would not change. I will now leave it lying aside for a couple of hours, just to make sure that it is just a matter of time until it miraculously wakes up again.
Does ANYBODY have any idea what might be going wrong here, anything? PLEASE, I would be so grateful for any support. There is only one small step left to do to achieve what I was trying to do, and it would be a huge setback if the entire project would fail because of it.
Many thanks,
RBNB
-
As an addition to my last post, this might help with the diagnostics: After attempting the database import procedure again and again, I got it to finish 2 or 3 times. However, a significant part of the database was always missing. After trying around a bit, I found out that the result would always be identical: precisely 2471 out of around 7500 files would remain without their proper database entry (in my case, I could judge that from the missing RATING which I gave to the tracks).
This sounds like one particular entry/file/whatever causes an error and therefore the procedure to abort, or what do you think? Is there any way to find what causes the error?
Thanks,
RBNB
EDIT: It occurred to me that I read about the "metadata log" somewhere else on the forum, which might give a strong indication if the file parser fails with always the same audio file. I activated it from the System > Debug menu, but... how can I READ that log now? The RB documentation says something about .metadata/log, but I can't find that folder anywhere on my iPod.
-
Hi everybody, particularly [Saint] and all those who might have followed the discussion earlier on the IRC channel.
I've got some new insight that might help finding the cause of the problem. I strongly assume that the file corruption (if there was any) must have occurred at an earlier stage, with the database import procedure actually doing its job perfectly (the metadata log showed that all files were processed, with no crash happening at any point).
This is what I found out: While I was testing the device (an iPod 6G 80GB modded with Tarkan's iFlash Quad adapter to hold three 128GB micro SD cards), I noticed stark volume differences between tracks. Usually this doesn't happen, since I use ReplayGain on ALL of my tracks. I checked it and found out: all tracks which seemed to have lost their metadata, also had lost their ReplayGain information! To me, this looks like the files were corrupted already when I transferred them to the device via USB, with the database function obviously not "recognizing" them as the files that the changelog.txt provides metadata for.
Since the 6G iPods have a 128GB limitation when formatting via iTunes, it's not possible to go the "safe way" by starting the Apple OF and transferring the files from there. It HAS to be done via Rockbox (there are often problems with RB's USB handler causing file corruption). Tarkan himself told me that since the new iPod 6G bootloader is being used and EMCORE is obsolete, the USB handler problems were supposed to be corrected - but I'm not sure this is entirely true.
Please let me know if this helps.
Best,
RBNB