Enhancement Suggestion: Dirwatch check for file for completion before playing audio. #121
AvalancheAddict
started this conversation in
Ideas
Replies: 1 comment 2 replies
-
In fact, there's already a hard-coded 2 second delay in the dirwatch function which I thought was enough to allow the file to settle down. Previously in v5 there was a configurable field to indicate how long to wait before ingesting the file, but this was not brought back in v6 as I thought it was unnecessary. No worries then, I will bring back this delay value in the next v6.1.10. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
For my suggestion to make sense, you will need to understand my scenario, then I think it will make more sense.
With the new #TGMHZ file mask feature added in v.6.1.8, I have completely revamped my connection to Proscan (via Dirwatch) which makes things much simpler.
By using these file name formats, it all comes together quite nicely:
Proscan: %YY%M%DD %TT %G %F
Rdio Scanner: #DATE #TIME #SYS #TGMHZ
The only problem is that Rdio Scanner will start playing the audio file before Proscan is completely done writing it, so what happens is, if it is a longer (say 30 seconds as an example) transmission, it will play say 5 seconds of audio (the part of the file that was written when Rdio Scanner grabbed it), and then once the file is done, Rdio Scanner will grab it again (if duplicate calls is disabled) and the second time it will play the whole file. Enabling duplicate call detection makes it even worse because then it plays the 5 second version and never plays the full version at all because it knows it is a duplicate (which it is).
I am working around this by having Proscan save to a temporary directory, then running a looping batch file to move the files to the dirwatch directory every 3 seconds. Windows knows the file is in use and won't move it until it is done, so if it's still being written during the first 3 second attempt, it will error out and then try it on the next 3 second attempt. This workaround does the job, but it is kind of clunky.
While I know Proscan is not really supported by Rdio Scanner, with the #TGMHZ tag making things so much simpler, it could easily be supported if this one little issue is resolved. I would think that other applications besides Proscan could be susceptible to this problem as well depending on how they write & lock the file.
My suggestion would simply be a either a way for the dirwatch function to determine if a file is still actively being written (this would be optimal), but a second and probably simpler option would be a delay for x seconds option when doing a dirwatch. The delay option would help, but would be the less desirable option, because if feeding Rdio Scanner from multiple sources, your dirwatch files would be further behind the files from other sources which could make things a little wacky, but I could live with that. I essentially live with it now due to my 3 second workaround.
I hope I have explained the scenario well enough for others to understand.
Thanks for your consideration.
Beta Was this translation helpful? Give feedback.
All reactions