On Tue, Mar 25, 2014 at 10:30 AM, Landry Breuil <lan...@rhaalovely.net> wrote: > On Tue, Mar 25, 2014 at 10:26:55AM +0100, David Coppa wrote: >> On Tue, Mar 25, 2014 at 10:07 AM, Landry Breuil <lan...@rhaalovely.net> >> wrote: >> > On Tue, Mar 25, 2014 at 10:01:01AM +0100, David Coppa wrote: >> >> On Tue, Mar 25, 2014 at 9:57 AM, Landry Breuil <lan...@rhaalovely.net> >> >> wrote: >> >> >> >> > Fwiw, after moving away the mpdstate file with the weird time entry, and >> >> > recreating my playlist, i havent had any issues with 0.18.9. Maybe in >> >> > some >> >> > circumstances mpd gets confused with its internal state (as brian linton >> >> > described in his STRs), but so far i've monitored the time: entry in the >> >> > current mpdstate file and it stayed at 'normal' values.. >> >> >> >> Nice to hear! >> >> >> >> Then, I'm ok with the update. >> > >> > Well, i'd rather have it properly fixed for a normal upgrade path. >> > Requiring users to remove/lose their state is not nice. >> >> Very simple fix: >> >> into patches/patch-doc_mpdconf_example, change the name of state_file >> from "/var/spool/mpd/mpdstate" to, e.g.: >> "/var/spool/mpd/state" ? > > I dont see how that fixes existing setups. I think digging into the code > and finding out the exacts STRs for the problem, and why it ends up with > that time overflowed value - check if that's really the source of the > problem we're experiencing, and checking that with upstream would be the > next steps .. for the MAINTAINER ;)
Sure, but ENOTIME now :)
