... the only method I ever got to work was EMCore ...
It is probably worthwhile to, and I feel as though I should, note that the current release of Rockbox Utility (and the git head implementation if you were to compile yourself) is not actually capable of installing a bootloader for the iPod 6G.
The current release and git head versions of Rockbox Utility can only update an existing Rockbox installation on this device, which as you might know is literally doing nothing more than extracting an archive to a destination.
The version of Rockbox Utility compiled and supplied by myself that is capable of bootloader installation on the iPod 6G has a number of patches (linked earlier in the thread) that are still pending review and submission. You are not only doing yourself a favour, but you are also doing myself, the lead developer of this project, and all those in the future a favour as well by being one of the first wave of early adopters.
Should be worth noting that the only way to find the 6th generation ipod option is to check the box in the corner to show the build, which is otherwise hidden by default.
Yes, unfortunately this is a weird little dance of necessity for the interim.
The iPod 6G is classified as "unusable" in our release system. As you know, this does not literally mean that it can not be used. Stable, unstable, and unusable all mean something fairly different to what one might expect them to in the normal, everyday usage of the words. Stable doesn't imply a guarantee of stability, nor does unstable imply instability, or unusable imply that it is literally unusable.
In our definitions unusable refers to the fact that a build exists for it, but there are some serious issues that limit it to advanced users or developers.
In the case of the iPod 6G, it is "unusable" in our terms because from an official point of view, we (Rockbox) offer no means to actually boot the binary we supply. Until fairly recently, the only way to boot the supplied binary was using emCORE (or iLoader before it, the spiritual successor to emCORE), which is a third party project that is not supported by Rockbox whatsoever. Now, even though there is a bootloader intended for submission in the near future, it still isn't a part of the Rockbox mainline source and no release has been made so it still falls into the "unusable" category.
Even though the modified Rockbox Utility is capable of performing a bootloader installation on this device, it is still getting the information about supported targets from Rockbox proper. When more people have tested this bootloader and the lead developer is confident that both the bootloader itself and the Rockbox Utility integration is fit for inclusion into mainline Rockbox then the target will be promoted to stable and users would no longer need to specifically elect to display unsupported installation targets in Rockbox Utility.
After the fresh install the build is working much better than previously as I have yet to have a panic error after trying to provoke a few (with emcore and an incorrect ipod video version of rockbox, there were a few things that would have caused this.)
I believe you may be confused here, could you clarify please?
There is absolutely no way that a build for the iPod Video 5/5.5G would boot on the iPod 6G at all. You would get a message from emCORE stating something to the effect (I cannot remember the exact wording offhand and I'm not in a position to check Freemyipod's sources presently) of there being a missing or incorrect rockbox.ipod binary and stating that you should plug USB and fix it.
The new boot is very quick and jumps right into rockbox which I do enjoy.
It is worth noting in the case of anyone else who still uses emCORE for the interim who may stumble upon this thread that emCORE is entirely capable of booting directly into Rockbox as well. This does not matter to you now of course, but this action was goverened from the emCORE settings menu under the 'fastboot' option.
Also no themes crash on this version either.
While this is a good thing, and I am perfectly willing to take the credit for it, this is not related to changing the bootloader in any way, shape, or form. As soon as you see the Rockbox splash screen at boot, the bootloader has already finished doing its job and has handed off control of the device to Rockbox.
The updated build of Rockbox you installed from the modified Rockbox Utility that I distribute is in itself unmodified and is built by the same build farm as all our other builds, and generated from the same sources.
It is likely that your user settings were conflicting in some fashion and that the process of formatting the device and reinstalling, and therefore returning to the default state of installation, is what has caused your issue(s) to disappear.
Does this 6thgen version already have the ssd "fix" implemented in it?
Not the one that you're probably thinking of from Beyondwind, no. As mentioned above the build of Rockbox you installed is completely unmodified. Now that you actually have the bootloader installed there is no real reason to continue using the modified Rockbox Utility I supplied, the release of Rockbox Utility that you can find linked in the sidebar is entirely functionally identical in regard to the installation of Rockbox itself (all it is actually doing is extracting an archive to the root of the device storage, you could do this yourself manually if you like and forget Rockbox Utility even exists).
You could use the official Rockbox Utility, my modified version with prof_wolfff's patches for bootloader installation support, or extract the ipod6g archive directly to the root of the device storage and each method would result in an identical outcome and install a verifiably byte-identical binary.
I assume it does as I have not noticed the battery draining at all when left off or on hold for some period of time but I wasn't sure.
Rockbox powers the hardware off completely when it shuts down, unlike the Apple firmware which will essentially "hibernate" (yes, entirely similar to your desktop, laptop, etc.) which allows for a much faster perceived boot time (when in reality it isn't booting at all). This is nothing new, Rockbox has always behaved this way on the iPods, and in this powered down state battery consumption should be very minimal indeed (though obviously it will be non-zero, because...physics/battery chemistry).
Regarding the device being on hold for extended periods, battery usage in this state will obviously depend on what the device is actually doing at the time. If the device is left on hold while not currently playing audio and in an otherwise idle state, due to various default settings battery usage will also be very minimal. The LCD and backlight would be powered down, the CPU would be on the minimum clock settings (we have boosted and unboosted CPU states), the HDD would be spun down and put to sleep, the clickwheel is powered down in the hold state, etc.
Battery usage in an idle state, especially on hold, should be very minimal. However nothing has changed in this regard for a very long time and as noted you are running an unmodified binary straight from our build farm to your device.
Any difference you may be seeing in battery consumption will either be observational bias, or a direct result of the installation forcing you to restore the device config to the default state.
All in all, glad to have you on board and I hope to see you around this community in the near and distant future. I am glad to be of service to you.
PS: If you are interested at all in configuring the device with a mind towards minimizing battery consumption, please don't hesitate to ask. There are a number of settings that are intended to provide the best user experience possible through their defaults (mainly revolving around hardware accessories and the visible user interface and core functions like the theme engine and database for instance) that can be altered to provide an increased runtime.