Thank you very much. I think we have enough evidence now to track the problem. No need for more logs.
@sa2000, any updates?
nothing yet - will discuss with the development team
Any new updates on this bug? I would love to be able to run my DVR again.
I am afraid it is still in the backlog. The issue only arises if more than one file is processed.
Which is 100% of the time I am using the DVR.
I am running a post processing script (built in feature) that generates extra files. Files should NEVER get lost.
My DVR has been turned off for months now. I think you should consider giving more priority for this bug.
As paying customers, this is getting pretty frustrating.
@sa2000 Any idea where this bug is in the queue for fixing?
Any updates? When will this bug be fixed?
sorry - it is still in the backlog. Will add a note to it
Hey all,
I got tired of waiting for a fix for this issue and ended up adding a directory watchdog to my video_utils code base if you want to check it out. It allows for specifying a script to run after recording completes. There is info on the github page, but some info follows:
The Watchdog
Using the python watchdog module, the Plex_DVR_Watchdog script monitors a given directory for changes. In this case, I set it to monitor my /path/to/TV Shows
directory. When a file is created, the watchdog checks to see if .grab
is in the file path. If it is, then the file is a new recording. If it isnât, it checks if the file has been moved from the .grab
directory, waiting for file to finish moving to its final location. After the file is done moving, a user-specified script is run on the file OR my code base takes over and processes the file. Note that all the processing takes place in the directory where Plex moved the file to; no more worrying about Plex moving files you created in .grab
.
Installing
To make sure there are no permissions issues, I have installed the package under the plex user using the following command
su - plex -s /bin/sh -c "pip3 install git+https://github.com/kwodzicki/video_utils --user"
On Linux, this will install the package into /var/lib/plexmediaserver/.local/
. You should be able to install where ever youâd like, I was just having some permissions issues.
On the github page there are examples of .service
files for getting the watchdog to run at startup as a service. Just adjust the path to the watchdog script to match your install location, use the --script
flag to set the path to your post-processing script, and set the directory to watch and it should work great.
A fix has been produced and will be going through the release / testing process
Server 1.18.1.1973 (public)
My server is indicating errors after my script exits. I build a shorter file(.ts) next to the recorded file(.ts), then take away the original and rename the new version. The filename provided by Plex (âŠEpisode title.ts) is appended to (âŠEpisode title - 23m43.ts) for the remaining file. I leave only the one new video file on exit and Plex relocates it as expected. Can we lessen the severity of this âSillyâ error, so important errors donât go overlooked?
One way around this that I played with (before deciding to not use the post processing option) was to create a hard link with the name of the original recording to my newly created file. Hard links take up essentially zero space and Plex still thought the original recording existed, so no more error. This obviously wonât work while the bug exists (there will be 2 files in the directory), but with a fix seemingly in the works, it should be an option.
It would be nice if Plex tried to find a video file in the recording directory, and assumed it was the recording, rather than looking for the specific recording, but from a coding stand point, I understand why they would want to warn a user if the recorded file disappeared.
Itâs a hard problem to solve when the technical abilities of users can vary widely. Sorry this doesnât really fix your problem.
from a coding stand point, I understand why they would want to warn a user if the recorded file disappeared.
Funny how this bug (for which the fix will hopefully get pushed to public soon) doesnât show an error in the recordings section though.
The recording just disappears, as if it was never scheduled in the first place.
Hard links are useful, but I keep the original recording of certain shows in the log directory for a backup, an automated edit would apply to all âcopies.â It was just a one line edit to avoid errors from the naming problem until itâs fixed. I already log the inode number for each incoming file, that is the most reliable way to track down a transient file. Iâll move to a trigger script or watchdog service if it gets too annoying.
Yes, except this is like the âCheck Engineâ light, it is there to scare the average user, but it doesnât tell the mechanic anything.
Iâm lucky, all my files make it home. This problem with multiple files is the priority. Glad to see itâs getting some attention. BewareofyourIFS,thatâshowthesethingshappen.
I never said their checking was perfect hahaha. Ideally there should be a check done after all files are moved also to make sure they ended up in the right place, then warn user if failed.
This is why I just moved to a watchdog; let plex do what it does and then Iâll do the processing after.
Has the fix been implemented into any of the newest updates? Havenât noticed it in the release notes on the forum.
The fix for the case of having more than 1 output file is part of 1.18.3.
I do not have dates for when It will be beta or public
Release 1.18.3 has just got released to Beta as Plex Media Server version 1.18.3.2111
See Release Notice Plex Media Server
- (DVR) Support moving multiple files during assimilation. (#9996)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.