What I did different this time was uninstalled v1.9.7.4460 before installing v1.11.1.4760. Normally I only uninstall if going from newer to older version. I then deleted the DVR and reinstalled it.
Appears that by not uninstalling the older PMS version before manually installing the latest it left things lingering behind that mucked up the works.
It’s been working for me and I didn’t delete any channels. Third automatic refresh of EPG just finished. First was 17:00 yesterday, second 02:10 this morning and third at 09:00 this morning. Have 14 days of guide data (today, 02/09/2018 to 02/22/2018).
@Plexer223 to uninstall 1.9.7, did you use dpkg -r plexmediaserver without deleting the /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/ directory? or did you started with a fresh install with no libraries?
Thanks, for now I have tried 3 out of the 4 options to get mine to refresh:
Delete and re-add dvr which only works once but further manual refreshes of the guide fails
Removing the epg db files so it rebuilds again with an initial refresh
Disabling problematic channels
Uninstalling the server app without removing the data, in my case I am using linux mint (dpkg -r plexmediaserver), and install the latest version ( I will try this option over the weekend)
Crashed again. kriss1427’s suggestion of nuking the db from the CLI is a good shortcut. Interestingly it’s hanging on the same channel again, and it reads in the log as if it’s an improperly terminated JSON record - just garbage repeating. Hopefully someone is working this as an issue.
While I’m not the expert Tim is on DVR I can shed some light as to what’s happening on Synology.
When you click ‘Install’,
DSM validates and unpacks the binary.
It then commands PMS to stop
At some X seconds later, after calling the stop() function, it overwrites the binaries (programs)
It then calls the installation script (where I make sure everything it setup correctly)
My installer makes certain the Plex share, user, and all other configuration settings are correct
After my routine exits, if you have checked “Run package after installation”, DSM will call the start() function
PMS starts up
If DSM started overwriting the old binaries before shutdown was completed, I can see where it can cause problems. I’ve never heard of such a case but it’s not impossible.
Because I have no control over the delay between commanded shutdown (by DSM) and when it overwrites the binaries, it’s best to stop PMS first and let it quiesce. DSM is supposed to make certain of this. I could add an extra check in the stop() function should it be necessary but will come with the tradeoff of another 5-10 seconds to actually install.
Also be advised, I keep the application binaries in the @appstore (Package Center) directories. Your metadata (library) is wherever you told the installer to place it (select the volume when installing). I do this because Synology does not let us downgrade. Storing data out on the main volume is how to safely get around that limitation. (programs in AppStore, data on the Volume)
@ChuckPA said:
While I’m not the expert Tim is on DVR I can shed some light as to what’s happening on Synology.
When you click ‘Install’,
At some X seconds later, after calling the stop() function, it overwrites the binaries (programs)
Thanks ChuckPA.
I always stop the PMS package service before upgrading or uninstalling it.
My quess is when the v1.11.1.4760 install overwrote the binaries left behind from v1.9.7.4460 that some old binaries were left that caused the issue?
If that happened, it’s clearly a fault in the DSM package manager.
I will test that specific case as soon as my Synology finishes its volume reconstruction.
If you were to stop PMS, back down to 1.9.7 and then upgrade to 1.10.1 while it’s running, that will tell us a lot about where the root cause is or is not.
If that is successful and then upgrade , again while running to 1.11.1, we will have a very clear picture of the sequence.
If you can get an error free upgrade from 1.9.7 - 1.10.1 - 1.11.1 , it would almost definitively be a function of the JSON entries in the database being needed before the database migrations (1.9.7 -> 1.11.1) completed. Tim and I can take that discussion offline as needed.
If you have the time and are willing to work through those sequences, i’ll do my verification here and we’ll cross check the results.
I’m willing to try but I don’t have the v1.10.1 spk pacakage, only kept the golden ones that worked for me (1.6.1.3722, 1.9.7.4460 and 1.11.1.4760). Can you provide a link to the v1.10.1 for me (1.10.1.4561 I assume)?
Couple questions;
re: If you were to stop PMS, back down to 1.9.7 and then upgrade to 1.10.1 while it’s running, that will tell us a lot about where the root cause is or is not.
I don’t think Synology will let me install 1.9.7 over 1.11.1, I would have to uninstall 1.11.1 first?
So you want me to update (install the new versions) while PMS is running?
And then kick off a manual EPG refresh after each to see if it errors out?
Never mind about a link to v1.10.1, just realized v1.10.1.4602 is the latest Public version. I just downloaded it.
Still waiting for answers to questions above in previous post.
You’re correct, you must first Remove 1.11.1 to get back to baseline 1.9.7. From there, you can walk the chain. When you get to the top, that’s when you must uninstall to get back to the bottom again.
Yes, After it has a few minutes to stabilize on the new version, then kick it off. Remember, the database changes (migrations) run for those first few minutes after any upgrade
OK, I just set advanced preferences to keep 25 log files, have debug logging turned on and verbose logging turned off.
Will stop/uninstall PMS, clear the log directory and start the journey.
I’ll need to get back to a working version for a recording scheduled in 8 1/2 hours tonight.
Currently waiting for the manual EPG refresh to finish on v1.9.7.4460.
Will PM you the logs when I’m all done.
Do want a copy of the databases from each version, before I update to the next version?
@ChuckPA
No errors in updating from version to version or from EPG refreshes, Now at v1.11.1.4760.
Will be sending you logs shortly in a PM.
Kept database backups from each version in case you need them.
A known problem (minor corruption of a few fields) and being worked on. It is not a fatal error. It retries and gets the correct data (Gracenote)
Migrations ran very smoothly and completely without incident concurrent with the DVR doing all its scheduling.
For PMS 1.10.1:
EPG updating correctly with no errors
Database upward migrations without incident
For PMS 1.11.1.4760
EPG updates normally
Migrates normally
DVR rechecks and initializes schedule normally.
Normal run through until PMS shutdown. (it was updating metadata when shut down but that’s normal. It recovers automatically)
Please hang on to the databases in case @timwoj wants to see them.
From what I see here, it is behaving perfectly.
It would be interesting to compare this clean run with the erred run. Again, Tim would know the significance of the differences a second pass might make.
Here’s the log from when I updated from v1.9.7.4460 to v1.11.1.4760 showing the JSON parse error.
I had stopped v1.9.7.4460 (without uninstalling) a few minutes before, then manually installed v1.11.1.4760 and started it.
EPG refresh automatically started at Feb 06, 2018 17:00:00.372
FAILED at Feb 06, 2018 17:00:24.511 with JSON parse error
