Sudden error in 4.2.0 version #42
Comments
|
This is the version that I actively run, and I cannot replicate the error. This error is happening during the script self-update portion, and what you have provided is the extent of the error messages? Which NAS model and version of DSM are you running the script on? I have been successfully testing with DS1019+ (x86_64), DSM 7.1.1-42962 Update 5. I was actually about to make v4.2.0 released/self-updatable now that DSM 7.1.1 Update 5 is publicly released. If you've been running it for weeks but it has only errored in the past few days, I would try the following:
|
|
Hmm.. Update and reboot fixed it.. Strange. For completeness: on 13 april it suddenly happened. Complete log: SYNO.PLEX UPDATE SCRIPT v4.2.0 for DSM 7 Script: syno.plexupdate.sh
Synology: DS920+ (x86_64), DSM 7.1.1-42962 Update 4
New Package: PlexMediaServer-1.32.0.6918-6f393eda1-x86_64_DSM7.spk Update newer than 7 days - skipping.. 13 april: SYNO.PLEX UPDATE SCRIPT v4.2.0 for DSM 7 jq: error (at :1): Cannot index string with string "tag_name"
Synology: DS920+ (x86_64), DSM 7.1.1-42962 Update 4
New Package: PlexMediaServer-1.32.0.6918-6f393eda1-x86_64_DSM7.spk Update newer than 7 days - skipping.. Update and reboot: Task: updateplex SYNO.PLEX UPDATE SCRIPT v4.2.0 for DSM 7 Script: syno.plexupdate.sh
Synology: DS920+ (x86_64), DSM 7.1.1-42962 Update 5
New Package: PlexMediaServer-1.32.0.6950-8521b7d99-x86_64_DSM7.spk Update newer than 7 days - skipping.. For now: it works (and it allready did. Only the check failed). Also the update of plex works) |
|
I'm glad to hear that the issue resolved itself and wasn't anything programmatic from my side of things, but this is something I continue to take seriously. I am not particularly happy when a reboot resolves an issue, and I will continue to do anything that I can to make the script resilient to issues like this. I don't know if you have noticed from past issues, but other people have experienced odd bugs before that I cannot recreate and that resolve themselves after a reboot. They are thankfully rare and seemingly not recurring after a reboot, but they have happened. They typically involve the inability to properly process a date-related variable - so your issue here is novel, and I find that disturbing. I can only surmise that there is an underlying problem/bug with the shell service environment. Thank you for providing the additional log detail. If you don't mind continuing this conversation just a little bit more: Would you tell me how long your Synology had been up/running before this issue started? Do you run any other shell scripts as recurring tasks? Thanks, |
michealespinola
changed the title
|
Sure to continue the story. Happy to share some thoughts... Some details: At first I suspected something like 13-04-2023 (normal date format in NL) to confuse it with 04-13-2023. Still this would have been noticed before starting the script (19 March). For other scripts: Only have some "Hyper Backup" scripts. Nothing worth mentioning. Could it be the jq is a bit buggy? (thinking out loud). I am not really into json or regex stuff. But whenever it tries to pull a string is erroring out, it might be usefull to do a but of debug logging (which is overwriting it with running the next run). Whenever you want more info from me tell me. Otherwise If you want me to test something, I can check it for you. |
|
Thank you. I appreciate the info and willingness to help further troubleshoot. I can't recall personally seeing or receiving any reports of jq-related issues like this before (even when I was actively learning/developing the jq portion of the script). I really only ever use jq on my Synology NAS (for a few different scripts I run), but I've never seen this particular error before. I can't fathom why it randomly (and just you) would have this kind of JSON object issue - and why would a reboot resolve it (???). Every once in a while I change how things are syntax'd in the script to make it more resilient/safer to glitches. I use linting tools and make revisions based on current best-practices for bash scripting to the best of my knowledge from books and commentary from various scripter/developer websites. Hopefully there is something I can similarly do with the jq syntax portions. Perhaps there is a more appropriate way that I should be capturing/iterating object data into strings. The problem ultimately is that without a repeatable issue, there is nothing to test and confirm against. I can only hope to never hear about the problem again. Well, I've got some jq syntax best-practices to review. You make a good point about debug logging. I appreciate the conversation to help me re-engage into the development thought process. Thanks again, |
|
The next script version (v4.3.0) will automatically create an output |
|
And so every "bad" thing can be used for "good". The culprit: ++ curl -m 900 -Ls 'https://api.github.com/repos/michealespinola/syno.plexupdate/releases?per_page=1'
It looks like too many github requests are killing the script at my side. In the end the debug saves the script. And whenever new issues occur, you can allways ask for debug log. |
|
Good with the bad indeed. My hours of trying to figure out that simultaneous debug output paid off. Redirections can be so quirky if your order of operations is not precise. I had assumed that this kind of rate-limit issue would be obvious in other ways. I'm disappointed in myself for not realizing this might be a culprit here, and asking you how often you run the script. Sites like GitHub and Docker absolutely rate-limit, and they both have lower thresholds for rate-limiting against unauthenticated sessions. Thankfully, I already have code I can implement that can catch/detect this kind of issue thanks to work I have been doing on another Plex-related script (the codec pre-loader). I will incorporate it into the update script as well so these kinds of issues will be more obvious in the future. You can learn a little bit more about the pre-loader script as outlined in the new/upcoming feature post #22. I also have a Docker script I wrote that can pass credentials so it can make more connections. I honestly don't think that Plex needs nearly that level of update checking, but I'll look into how adaptable what I did for my Docker script might be for Plex. Two questions: How often were you running the script? Did curl also return any specific HTTP status codes as well? 3xx, 4xx, 5xx, etc? I'm going to re-open this issue until the curl error-trapping is complete and a new update is released. Thanks, |
|
Functionality has been added to the latest release version |
|
Thanks Michael. Noticed this morning you created a new version. Thanks for your nice updater. Very happy I do not need to verify and see if updates are arriving. |
|
From things I've learned along the way while working on adding this functionality: Unauthenticated GitHub connections are 60 per hour per IP. So, while I've got the unauthenticated basics done, I'm still working on working with Authenticated connections. I imagine that for some of us (like you and me) that use things like HA and do various forms of update checking for multiple GitHub-based programs, that hitting the 60 might become an issue in the future. I've already had to do similar with my Docker updating checking scripts (unauth is 100, and basic account auth bumps you up to 200). |
Hi,
I am using the 4.2.0 version now a couple of weeks and the update mechanism is working very good.
But the last few days I receive an error in the first block (check for newer scripts) :
SYNO.PLEX UPDATE SCRIPT v4.2.0 for DSM 7
jq: error (at :1): Cannot index string with string "tag_name"
jq: error (at :1): Cannot index string with string "published_at"
jq: error (at :1): Cannot index string with string "body"
Script: syno.plexupdate.sh
Script Dir: /volume1/homes/admin/scripts
Running Ver: 4.2.0
I did not alter or modify the script.And it was working ok till i guess last week. (errorred out on 13 april perhaps a date issue? )
The update function for plex works though. Any ideas what's wrong?
Mike
The text was updated successfully, but these errors were encountered: