Third Party > Repairing and Upgrading Rockbox Capable Players
iPod Video 5G with iFlash adapter - is RockBox really hopeless in that case?
RockBoxNewB:
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
cereal_killer:
--- Quote from: RockBoxNewB on October 02, 2016, 12:50:55 PM ---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..."?
--- End quote ---
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.
--- Quote from: RockBoxNewB on October 03, 2016, 03:27:49 AM ---Is there any way somebody could supply a pre-filesystem-rework build with LOAD TO RAM still included?
--- End quote ---
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)
RockBoxNewB:
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
[Saint]:
--- Quote from: cereal_killer on October 03, 2016, 06:31:23 AM ---
--- Quote from: RockBoxNewB on October 02, 2016, 12:50:55 PM ---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..."?
--- End quote ---
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.
--- End quote ---
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.
--- Quote from: cereal_killer on October 03, 2016, 06:31:23 AM ---
--- Quote from: RockBoxNewB on October 03, 2016, 03:27:49 AM ---Is there any way somebody could supply a pre-filesystem-rework build with LOAD TO RAM still included?
--- End quote ---
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
--- End quote ---
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]
RockBoxNewB:
Hi [Saint],
Thanks for your once again "enlightening" insights.
--- Quote from: [Saint] on October 09, 2016, 05:26:58 PM ---
--- Quote from: cereal_killer on October 03, 2016, 06:31:23 AM ---
--- Quote from: RockBoxNewB on October 02, 2016, 12:50:55 PM ---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..."?
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version