starred/Video_Station_for_DSM_722

Fork 0

mirror of https://github.com/007revad/Video_Station_for_DSM_722.git synced 2026-04-25 08:15:54 +03:00

[GH-ISSUE #94] False positive "ERROR Starting Video Station failed!" (line 432) although service runs #35

New issue

Closed

opened 2026-03-12 19:02:33 +03:00 by kerem · 3 comments

kerem commented

2026-03-12 19:02:33 +03:00

Owner

Originally created by @HaukeMEYN on GitHub (Jan 10, 2026).
Original GitHub issue: https://github.com/007revad/Video_Station_for_DSM_722/issues/94

Hello,

I'm using script v1.4.19 on a DS920+ with DSM 7.3.2-86009 (geminilake x86_64) as a scheduled task after reboots to assure the VideoStation is running (also after a restart following an automatic version update that would uninstall VideoStation).

Problem:
The script reports after successful execution:
Line 432: ERROR Starting Video Station failed!
progstatus called from package_start line 537
Task Scheduler Status: 1 (Interrupted)

Log excerpt:
Video_Station_for_DSM_722 v1.4.19
DS920+ DSM 7.3.2-86009
CPU geminilake x86_64

Running from: /volume1/backup/HW/Synology_DS920+/Migraton/Video_Station_for_DSM_722-1.4.19/videostation_for_722.sh
Using CPU type: x86_64

Advanced Media Extensions 30.1.0-3005 already installed
Video Station 30.1.0-3153 already installed
Media Server 20.0.5-3152 already installed
Starting Video Station.
Line 432: ERROR Starting Video Station failed!

Observation:

Video Station runs perfectly fine anyway (Package Center: "Running", DS Video works).
synopkg status VideoStation shows "running".
Error occurs sometimes execution after reboot.

Suspected cause:
The synopkg start VideoStation command returns exit code 1 because Video Station was already started automatically by DSM before the script runs. The progstatus function treats any !=0 exit code as an error.

Suggestion:

Before package_start VideoStation, check: if ! synopkg status VideoStation | grep -q "running"

Could you improve the check so the task status accepts if VideoStation is already running and so to show "Finished" instead of "Interrupted" as this triggers a failure report that itself triggers server error handling across the installed devices?

Thank you!

Originally created by @HaukeMEYN on GitHub (Jan 10, 2026). Original GitHub issue: https://github.com/007revad/Video_Station_for_DSM_722/issues/94 Hello, I'm using script v1.4.19 on a **DS920+ with DSM 7.3.2-86009 (geminilake x86_64)** as a scheduled task after reboots to assure the VideoStation is running (also after a restart following an automatic version update that would uninstall VideoStation). **Problem:** The script reports after successful execution: Line 432: ERROR Starting Video Station failed! progstatus called from package_start line 537 **Task Scheduler Status: 1 (Interrupted)** **Log excerpt:** Video_Station_for_DSM_722 v1.4.19 DS920+ DSM 7.3.2-86009 CPU geminilake x86_64 Running from: /volume1/backup/HW/Synology_DS920+/Migraton/Video_Station_for_DSM_722-1.4.19/videostation_for_722.sh Using CPU type: x86_64 Advanced Media Extensions 30.1.0-3005 already installed Video Station 30.1.0-3153 already installed Media Server 20.0.5-3152 already installed Starting Video Station. Line 432: ERROR Starting Video Station failed! **Observation:** - Video Station **runs perfectly fine** anyway (Package Center: "Running", DS Video works). - `synopkg status VideoStation` shows "running". - Error occurs sometimes execution after reboot. **Suspected cause:** The `synopkg start VideoStation` command returns exit code 1 because Video Station was already started automatically by DSM before the script runs. The `progstatus` function treats any !=0 exit code as an error. **Suggestion:** - Before `package_start VideoStation`, check: `if ! synopkg status VideoStation | grep -q "running"` Could you improve the check so the task status accepts if VideoStation is already running and so to show "Finished" instead of "Interrupted" as this triggers a failure report that itself triggers server error handling across the installed devices? Thank you!

kerem closed this issue

2026-03-12 19:02:38 +03:00

kerem commented

2026-03-12 19:02:44 +03:00

Author

Owner

@007revad commented on GitHub (Jan 10, 2026):

If the package is already installed the script just checks if it is installed and running with synopkg is_onoff videostation which only returns 0 or 1.

The false error is caused by the script not checking if the package is currently starting.

I've just found that in DSM 7.2 and later when a package is starting synopkg status <pkg-name> returns 55. DSM 7.1 and 6.x returns 4 (though that's not relevant for this script).

root@SENNA:~# synopkg status ContainerManager; echo $?
{"aspect":{"active":{"status":"starting","status_code":311,"status_description":"translate from systemd status"},"working":{"status":"starting"}},"description":"Status: [311], package is stopped","package":"ContainerManager","status":"starting"}
55

Can you try v1.4.20
https://github.com/007revad/Video_Station_for_DSM_722/releases/tag/v1.4.20

@007revad commented on GitHub (Jan 10, 2026): If the package is already installed the script just checks if it is installed and running with `synopkg is_onoff videostation` which only returns 0 or 1. The false error is caused by the script not checking if the package is currently starting. I've just found that in DSM 7.2 and later when a package is starting `synopkg status <pkg-name>` returns 55. DSM 7.1 and 6.x returns 4 (though that's not relevant for this script). ``` root@SENNA:~# synopkg status ContainerManager; echo $? {"aspect":{"active":{"status":"starting","status_code":311,"status_description":"translate from systemd status"},"working":{"status":"starting"}},"description":"Status: [311], package is stopped","package":"ContainerManager","status":"starting"} 55 ``` Can you try v1.4.20 https://github.com/007revad/Video_Station_for_DSM_722/releases/tag/v1.4.20

kerem commented

2026-03-12 19:02:49 +03:00

Author

Owner

@HaukeMEYN commented on GitHub (Jan 12, 2026):

Many thanks for the investigation and the very clear synopsis. Upon reading it, I'm quite confident this will resolve the issue. In any case, I've installed the updated script and will monitor the logs for a few days before checking and reporting back.

@HaukeMEYN commented on GitHub (Jan 12, 2026): Many thanks for the investigation and the very clear synopsis. Upon reading it, I'm quite confident this will resolve the issue. In any case, I've installed the updated script and will monitor the logs for a few days before checking and reporting back.

kerem commented

2026-03-12 19:02:54 +03:00

Author

Owner

@HaukeMEYN commented on GitHub (Jan 16, 2026):

The reported issues did not occur anymore. Case closed.

@HaukeMEYN commented on GitHub (Jan 16, 2026): The reported issues did not occur anymore. Case closed.

kerem referenced this issue

2026-03-12 19:05:24 +03:00

[PR #37] [MERGED] Sync from main #63

kerem referenced this issue

2026-03-12 19:05:24 +03:00