Improved performance, but since 9.9.20 I feel like this isn't necessary anymore, at least on my rev B pi.
I agree, with 0.4.0rc1 there didn't seem to be any noticeable difference, I just forgot to remove the USB stick from the Pi I tried to update this morning.
I did a manual update to RC2 (copy the needed 4 files to "update" and reboot) all went well. after playing a while a got a message that an update is available, update downloaded, update unpacked. after a reboot (and the updating messages at the boot) I was back to rc1... shock! then again, update available, update downloaded, update unpacked messages. reboot. i'm rc2 again... confused...
The closed issues to rc2 lists "missing plex windows definitions" as closed. yes, it's closed, but not included in the release. Is this the only issue thats closed but not included ? A bit confusing...
I, like a number of people run both an SD card and USB stick, I think that the update has got screwed and overwritten the config files on the SD card so that it's not seeing the USB stick as the main device, the auto update updated the files on the USB but not the SD card therefore on reboot it is running from the SD card (which is still at rc1).
Give me an hour to check this out and I'll post back my findings.
Regards.
Decided not to continue with USB stick (see other post above).
The problem seems to be with spurious update files.
I now have a stable rebootable Rasplex consistently running 0.4.0rc2 after several reboots.
After some investigation here's how I did it.
1. Reflashed SD card with 0.4.0rc2.
2. Inserted SD card into Pi and powered on, it will resize the SD card as the 'growstorage' command has been reimplemented in this version - fine by me, but others may wish to edit tis out before loading SD card in their Pi.
3. Follow the prompts for the Rasplex Settings, I noticed while doing this that a message came up telling me that an update had been downloaded, presumably as autoupdate is enabled by default.
4. Turned off autoupdate in the Rasplex Settings, turned off 'Automatically check for updates' in Preferences, System.
4. Fired up Cyberduck on my MacBook, navigated to the hidden .update folder and deleted all of the contents.
this is important btw. otherwise upon reboot it will check for updates (presumably at sourceforge where the latest available update is rc1) and then "upgrade" to rc1 IOW factually performing a downgrade... doh!
if you disable automatic upgrades all is well, though.
It's really odd that autoupdate is causing issues for some people.
I suspect that he md5 is legitimately failing for some reason... but seems like a huge coincidence, as we've had almost a hundred people successfully update.
Thanks all for reporting the problems, we'll make sure the update process is less bumpy in the future.
this is important btw. otherwise upon reboot it will check for updates (presumably at sourceforge where the latest available update is rc1) and then "upgrade" to rc1 IOW factually performing a downgrade... doh!
if you disable automatic upgrades all is well, though.
thanks fschulze!
Autoupdate checks only on github, it's very weird that it is showing you rc1
Can the people having this autoupdate issue give some more details ?
When the updated version has been downlaoded you should have a menu displayed in home screen named "Update & Restart".
There might be some confusion about when it's finished and if you would reboot before the update has completed, then that would explain the checksum error.
We would appreciate some further feedback on what is happenning so that we can have this not happen again in a near future.
Deleting '.plexht/userdata/plexupdateinfo.xml' should allow you to rerun the update. We will fix this in future releases to allow easier update retries.
Can the people having this autoupdate issue give some more details ?
When the updated version has been downlaoded you should have a menu displayed in home screen named "Update & Restart".
There might be some confusion about when it's finished and if you would reboot before the update has completed, then that would explain the checksum error.
We would appreciate some further feedback on what is happenning so that we can have this not happen again in a near future.
Thanks for your help :)
After an update to RC2, if you have autoupdate enabled, it goes into a loop. "Upgrade" to RC1, real upgrade to RC2, "upgrade" to RC1... I've done about 6 updates today... manual, auto... any combination seams to lead to the same loop...
On top of that, not many of my movies freeze after few seconds and only hard reboot brings it back... grrrr.......
It's really odd that autoupdate is causing issues for some people.
I suspect that he md5 is legitimately failing for some reason... but seems like a huge coincidence, as we've had almost a hundred people successfully update.
Thanks all for reporting the problems, we'll make sure the update process is less bumpy in the future.
-Dale
OK, but have they rebooted their Pi's since updating?
I don't know if this helps but I updated successfully to rc2. It rebooted twice automatically during the process and I can confirm rc2 because music playback is fine.
However if I go into pref => system => software update I notice that the Update Channel has reverted back to stable, and Auto check for updates is checked again, even though I had it unchecked before the update.
So I've unchecked Auto check, and changed the Update Channel to Prerelease. Because I'm thinking if I was to reboot the pi again, Rasplex would look for the latest Stable (rc1) and update to that instead?
Can the people having this autoupdate issue give some more details ?
When the updated version has been downlaoded you should have a menu displayed in home screen named "Update & Restart".
There might be some confusion about when it's finished and if you would reboot before the update has completed, then that would explain the checksum error.
We would appreciate some further feedback on what is happenning so that we can have this not happen again in a near future.
Thanks for your help :)
If you look back at my original post, the update completed successfully, after checking on various fixes to determine what had been fixed I rebooted, about 20 minutes after the update had completed, when it reboots is when it downloads another update and then proceeds to install that update, unless auto update is turned off. A user won't necessarily know that files have been placed in the .update folder, when you reboot it then does what it is supposed to do and writes the files in the .update folder back to the SD card's flash directory which results in having 0.4.0rc1 reinstalled.
There must be some internal code that is looking at a different source for updates as it always fetches the rc1 files.
I repeated this a number of times before finally found out that turning off auto update and clearing the contents of .update solved the problem.
We believe that this was a conflict resulting from the old update system pointing at rc1 and the new update system pointing at rc2.
We're very sorry for this.
We forgot about the old system... oops. Anyways, we pointed it at rc2 now, so theoretically this problem should eventually resolve itself as it should just detect rc2 as the new release to use eventually (I forget what interval it runs on). In this way, we can use the source of the problem to solve the problem.
There should be no more update loops.
There are a few possible solutions:
1) Wait for the OpenELEC updater to update to rc2
2) deleting '.plexht/userdata/plexupdateinfo.xml' via ssh then using the software update inside the app
Great, a new version of rasplex comes out and I'm stuck at work, missing all the update loops fun ;)
Thanks for your ongoing dedication to this great project!
Heh... 'fun'...
These are the nightmares you have when you roll out an update system. We're lucky that the old update system allows us to at least fix the problem, but if you send out an update that breaks updates altogether... that's just brutal.
it's great that you take this issue so seriously but I think I can speak for the other users in this thread (at the very least) that not only is these types of bugs are acceptable in a non stable release of any type of software, the nature of your volunteered work on an amazing free product is very highly appreciated and if anyone has a problem with this or any other bug, they can go screw themselves.