(2017-06-16, 23:04)mikeb8591 Wrote: Ok, I just discovered that with my 0612b build, I marked _one_ show using 'marked unwatched' and it did. When I backed out of that 'folder' all the series were showing the folder icon again, instead of the 'watched' check mark. and Indeed EVERY show in the other folders changed to 'unwatched' (except some I'd started watching, which remained marked correctly) EXCEPT the remainder of the episodes (siblings?) in the series I where I marked the episode unwatched. So I went into another series, and marked an episode unwatched, went back into the original series, and they were all marked unwatched too.

The change holds over a reboot. All my episodes now show correct status.

Thanks!

(2017-06-16, 23:01)pyrodex Wrote: 0615 http://sprunge.us/SaAY
0614 http://sprunge.us/igCB

I can't confirm physically at this time but you can see the bluetooth module is found in 0614 but not in 0615.

Could it be something with alsa as seen in this error on 0615

Code:

Jun 14 22:04:25 denhtpc pulseaudio[290]: E: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez was not provided by any .service files

(2017-06-16, 23:57)Milhouse Wrote: The only change in #0612b is the addition of PR12295, which is also included in all subsequent builds since #0613, so I'm not sure that's related otherwise you'd see the issue fixed in #0613, #0614 and #0615. However the latest build, #0616, does include PR12311 which @Koying thinks might help your situation so please test #0616 thoroughly and report if the issue is now resolved - thanks!

(2017-06-16, 23:44)Milhouse Wrote: @anthonws when did this behaviour start, with #0615, or earlier? What do you have connected to your RPi (on USB etc.)? What model is RPi?

Checking (and uploading) dmesg would be the first step, but obviously if the device is freezing solid (with no network) then you can't grab them once the freeze has occurred, so they may not contain anything relevant (but you never know).

(2017-06-17, 01:38)anthonws Wrote: p.s. Here's the current dmesg output: https://pastebin.com/nk92PYWe

(2017-06-17, 01:47)Milhouse Wrote: So it sounds like whatever issue you had (which started with #0403) you can no longer reproduce after changing some watched statuses... right? Perhaps there was some corruption in the videodb, which has now been "fixed" by toggling the status. Unfortunate timing, but if it was random corruption then maybe there's no point trying to fix it.

(2017-06-17, 04:11)mikeb8591 Wrote: Videodb existed before 11901 though right? Seems odd that it followed that change, unless something just didn't get converted correctly but got fixed when I toggle the value for a series episode. Hard to visualize what could have gone wrong like that.

(2017-06-17, 02:03)Milhouse Wrote:

(2017-06-17, 01:38)anthonws Wrote: p.s. Here's the current dmesg output: https://pastebin.com/nk92PYWe

So that's build #0613 with kernel 4.11.4.

Given the lack of any other problem reports of a similar nature while using this kernel (average 200 RPi2 daily downloads, since #0607) I'd say it's more likely to be something specific to your hardware/environment (SD card, power supply, power cable etc.).

If it continues after a clean installation then post again.

It might be useful to leave "bcmstat.sh y" running in an ssh window as this will record any under-voltage events - a "U" in the "UFT" column means an under-voltage event is currently taking place, a "u" means an under-voltage event has taken place (since the start of the script), and ctrl-c (to end the script) will show the total number of under-voltage events since the script started running.

(2017-06-17, 04:11)mikeb8591 Wrote:

(2017-06-17, 01:47)Milhouse Wrote: So it sounds like whatever issue you had (which started with #0403) you can no longer reproduce after changing some watched statuses... right? Perhaps there was some corruption in the videodb, which has now been "fixed" by toggling the status. Unfortunate timing, but if it was random corruption then maybe there's no point trying to fix it.

That would certainly explain why I appeared to be the only one seeing it. :-( Next time I see something like this, I'll be sure to try toggling it before reporting a problem. Videodb existed before 11901 though right? Seems odd that it followed that change, unless something just didn't get converted correctly but got fixed when I toggle the value for a series episode. Hard to visualize what could have gone wrong like that.

Anyway, thanks again for the help!