[Rejected] Use Schedule.Directory property when creating filename (1 Viewer)

[Oxan]

Hi,

Currently the Schedule.Directory property is never used. I think it would be nice to use this property when creating recording filenames, so that later on plugins can set the directory in which recorded programs are saved. I personally want to use it because my EPG data isn't always complete or correct and now everything is saved in the wrong folder. Patch is against 1.1.2, but should apply cleanly to trunk, and I'm using it for two weeks now without problems.

Index: TvEngine3/TVLibrary/TvService/Scheduler/RecordingDetail.cs
===================================================================
--- TvEngine3/TVLibrary/TvService/Scheduler/RecordingDetail.cs	(revision 27069)
+++ TvEngine3/TVLibrary/TvService/Scheduler/RecordingDetail.cs	(working copy)
@@ -305,6 +305,9 @@
       else
         fileName = strInput.Trim();
 
+      /* Prepend Schedule.Directory property */
+      if (Schedule.Directory != string.Empty)
+        subDirectory = Schedule.Directory + '\\' + subDirectory;
 
       if (subDirectory != string.Empty)
       {

 

[chemelli]

, evaluating...

Simone

 

[jameson_uk]

The problem with this is that the value you are using is not actually set anywhere therefore to use it you need to start hacking around in the database or installing other plugins. It would then be quite easy to break recording with an invalid file name.
The other issue is that I am not 100% sure this would be limited in scope to the change you have made. There are potentially other areas that would need the path changing too.

Therefore rejecting this change as currently there is now way of actually using it.

 

[Oxan]

The problem with this is that the value you are using is not actually set anywhere therefore to use it you need to start hacking around in the database or installing other plugins. It would then be quite easy to break recording with an invalid file name.

Yeah, but you have to start somewhere: no one will implement a method to set a not-used property. Also, I don't think implementing the usage of this property will increase the chance that someone messes with the database; he/she doesn't know that the property is used. I think we can assume that people who are smart enough to look it up in the code are also smart enough to not fill the database with garbage

The other issue is that I am not 100% sure this would be limited in scope to the change you have made. There are potentially other areas that would need the path changing too.

I've been using it for 2 months now and I haven't seen any other place where the path should be changed too.