Closed ytsejam1138 closed 4 months ago
You didn't state your script version, but this is likely a duplicate of #26. You will have to update the code manually to the latest version. If you would prefer to edit the fix into your existing code, the codeblock that needs to be replaced from that issue can be found here:
https://github.com/michealespinola/syno.plexupdate/blob/v4.0.2/syno.plexupdate.sh#L67-L80
Sorry about that, I'm running the latest version 4.1.0.
I've just tested 4.1.0 against both public and beta channel updates and do not see an issue in my environment. Could you try replacing your existing code with a fresh download of 4.1.0?
I replaced the script with a fresh download and I still get the same error. I have been running your script since 3.0.2e without any issues. In fact, I have been running 4.0.1 since it was released running every night without any problems until it ran yesterday at 12:00am.
I hate making a request like this, but would you try rebooting your NAS? I want to think this is some sort of glitch, because we are otherwise on very similar platforms and it isn't making a lot of sense to me why you are getting a date-related error.
If the error persists after a reboot, please send me the output of running the script in bash debug mode by using a command similar to this:
bash -x /volume1/homes/admin/scripts/bash/plex/syno.plexupdate/syno.plexupdate.sh
If you prefer, you can redirect the debug output into a file with a command like:
bash -x /volume1/homes/admin/scripts/bash/plex/syno.plexupdate/syno.plexupdate.sh 2>/volume1/homes/admin/scripts/bash/plex/syno.plexupdate/syno.plexupdate.debug
(this will make a debug file in the same directory as the script)
Post the debug code here while being sure to sanitize it of any identifiable information (delete your "Plex Token", etc). If you'd prefer, you can email the debug code to me at michealespinola+syno.plexupdate@gmail.com.
I meant to note, if you want or need to do all of this within DSM, simply add the '-x
' to the user-defined script setting in the DSM Task Scheduler.
To see the debug output (after running the task):
I'm used to opening up an SSH terminal and forget that some people don't do that.
Thank you so much for all your help. Rebooted, ran the script and it completed without any errors. If this was a Windows machine, a reboot would have been the first thing I tired. :)
Exactly! Hahah, I'm also reluctant to reboot the NAS because its not Windows. But a glitch is a glitch!
Glad to hear it resolved the issue.
I had this issue as well at https://github.com/michealespinola/syno.plexupdate/issues/29
Turned out, it was DNS. Forgot I had shut down the VM (temp, for hardware upgrade) that controls DNS and DHCP was still handing out that IP.
So Synology had an invalid DNS entry. Fixed that and this issue resolved it.
So in this case, I'd recommend the script verify that DNS is working and if not, stop and notify in the log.
I have the same problem, tried to reboot the NAS - but get the same error:
SYNO.PLEX UPDATE SCRIPT v4.1.0 for DSM 7
Script: syno.plexupdate.sh
Script Dir: /volume1/Scripts/SynoPlexUpdate Running Ver: 4.1.0 Online Ver: 4.1.0 Released: 2022-07-18 19:34:39+02:00 (224+ days old)
No new version found.
date: invalid date '@' Synology: DS920+ (x86_64), DSM 7.1.1-42962 Update 4 Plex Dir: /volume1/PlexMediaServer/AppData/Plex Media Server Plex Token: xx (NEVER POST OR SHARE THIS) Running Ver: 1.31.1.6733
"UNABLE TO CHECK FOR LATEST VERSION OF PLEX MEDIA SERVER"
Both "UNABLE TO CHECK FOR LATEST VERSION [...]" responses (for the script self-check as well as checking for the latest version of Plex) occur when the script is unable to connect-to/retrieve their corresponding webpages of data. This can be the result of multiple external factors between you and either GitHub (for this script) or Plex's update servers. It can be DNS, routing, server down, etc.
I will put it on my to-do list to incorporate a basic diagnostic check to make this more easily identified and understandable.
date: invalid date '@'
Please see this previous comment for the '@
' issue, and answer the same questions and follow the same instructions. This issue is typically cleared with a reboot of the NAS, although its still unclear what can causes the issue.
@kspreevie, are you still having this issue? Are you able to provide that extra logging information?
now it works, I rebooted my NAS 3 times, issue doesnt appear anymore. thank you!
Am Do., 2. März 2023 um 23:28 Uhr schrieb Micheal Espinola < @.***>:
@kspreevie https://github.com/kspreevie, are you still having this issue? Are you able to provide that extra logging information?
— Reply to this email directly, view it on GitHub https://github.com/michealespinola/syno.plexupdate/issues/35#issuecomment-1452644221, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6FH23AVTPLLPLONTKLVNOLW2ENHXANCNFSM6AAAAAASOOPCNE . You are receiving this because you were mentioned.Message ID: @.***>
Glad to hear that a reboot resolved it. If it ever happens again, please try to use that '-x
' flag and send me your log. I am still very much trying to understand what is happening to cause this misinterpretation of basic date/time information.
Hello: Thanks for the script, I was trying to use it and it always gave me the "Unable to Check for Latest Version" error. Even after 3 restarts and verifying the settings on the router and DNS. The only way I could get it to work was by changing the script. The issue seems to be in the curl command where the -m parameter is expecting a numerical parameter, but it's empty. To fix this, I provide a numerical value for the -m parameter. After this it ran perfectly.
` curl -i -m 10 -Ls 'https://api.github.com/repos/michealespinola/syno.plexupdate/releases?per_page=1'
If you are observing that the '-m' parameter isn't being assigned a value (the default should be 900), then it sounds like something is going wrong in the creation of, or loading of, the 'config.ini' file (NetTimeout). Can you verify it exists and what its contents are?
When looking at the script code, its creation and loading starts at around line 41. This script uses a config.ini so that parameters can be set/modified without altering the base code.
Certainly in the config.ini the NetTimeout value was at 0. I set it to 900 and the base was returned to the original and it ran without errors. Thanks for the help, excellent work!
Glad to hear it's resolved! But, this does bring up an interesting dilemma, in that some values can be too small! I'll have to put in a check for this, so thanks!
I've been getting this error the last few days:
date: invalid date '@' Synology: DS918+ (x86_64), DSM 7.1.1-42962 Update 2