Recordings file name should include date/time, and network ID

[DSperber]

As I stated before, the default file naming format produces unique filename for each specific show episode regardless of when/where it was recorded from. Adding the channel name all the time would break that.

I don't see how this is true. What makes the addition of 7 more characters defeat the uniqueness of the entire total string of characters?  Just make believe the program name itself (in the high-order leftmost positions of the file name) were simply 7-characters longer? Doesn't matter what those 7 characters are, they're just 7 more characters.

So what "breaks" in the unique filename notion because of what I'm looking for? Just as unique as before since the already-uniqueness of the rest of the string of character into which we're essentially adding a "constant", how does this damage anything at all?

Please elaborate what is broken by insertion of effectively a "constant string"?

[mvallevand]

Providing the channel number and channel oid in postprocessing gives you all the per channel customization you can ask for.

For what you want I'd use my earlier suggestion and set up a separate recording directory folder for ATSC 3.0 files and use that instead of thinking one dimensionally in the Default folder

Martin

[BrettB]

I'm really trying to understand why the filename matters.  You can view the recordings in NextPVR with nice names and all kind of details.  You can even use something like Kodi to see them.  It seems like you're trying to recreate some file based viewing system based the old Windows Media Center, and that's going to be hard to do with basically any modern DVR software.  I suspect many others here are trying to help you but similarly confused about why you are spending so much time trying to recreate something so old.

Well at the moment, there is nothing in the external file name that indicates whether it is from the ATSC 1.0 or 3.0 version of a channel. Same file name format, in the same sub-folder for the program.

If what you are really concerned about is whether the recording is from an ATSC 1.0 or ATSC 3.0 channel, then I'd think you might want to split your recordings into 2 recording folders: 1 for ATSC 1.0 channels and 1 for ATSC 3.0 channels. You could either do that by specifying the recording directory when you schedule recordings or automatically by moving recordings to the appropriate folder in your postprocessing.bat file based up on the channel number which is already passed as a parameter to the postprocessing.bat file.

[BrettB]

I don't know how objectionable an actual change to the filename is, but sub is one person doing this in his spare time for basically nothing (I suspect the donors and ad revenue from the site amount to not much). I know there are other feature requests that I'd rate much higher than adding something to the filename for one person, so I'd object to the change just in terms of prioritization.

I whole heartedly agree. What you are asking for is something very esoteric and there are fairly simple ways to accomplish it if you really want to. I definitely want sub working on things that can't currently be done at all rather than adding features for a single user which can already be done via NextPVR as it currently exists.

[BrettB]

As I stated before, the default file naming format produces unique filename for each specific show episode regardless of when/where it was recorded from. Adding the channel name all the time would break that.

I don't see how this is true. What makes the addition of 7 more characters defeat the uniqueness of the entire total string of characters?  Just make believe the program name itself (in the high-order leftmost positions of the file name) were simply 7-characters longer? Doesn't matter what those 7 characters are, they're just 7 more characters.

So what "breaks" in the unique filename notion because of what I'm looking for? Just as unique as before since the already-uniqueness of the rest of the string of character into which we're essentially adding a "constant", how does this damage anything at all?

Please elaborate what is broken by insertion of effectively a "constant string"?

Right now, the default file name generated for a show is something like "The.Amazing.Race.S33E03.Who.Has.This.One.in.the.Bag.ts". That show will get the same unique file name whether it is recorded from channel WCCODT or channel USAHD or any other channel.

[mvallevand]

Sub has said he is not adding it and there is enough information for the user to research how to do it himself in a batch file so let's call this solved and move on.

Martin

[DSperber]

Right now, the default file name generated for a show is something like "The.Amazing.Race.S33E03.Who.Has.This.One.in.the.Bag.ts". That show will get the same unique file name whether it is recorded from channel WCCODT or channel USAHD or any other channel.

I'm sorry, but I don't understand what you've tried to demonstrate here. In fact isn't it true that if that program were aired on WCCODT or USAHD, that the file name would be exactly what you showed? And isn't that NOT UNIQUE, but duplicated?? Sure there are additional minor appendages providing date/time to differentiate but isn't the high-order portion actually a DUPLICATE from both recordings?

I guess maybe I'm still not understanding what you're trying to say, but it seems that as things are right now both recordings show:

   The.Amazing.Race.S33E03.Who.Has.This.One.in.the.Bag.ts

And I'm saying that simply by inserting station ID if anything the resulting names for the two recordings become absolutely MORE unique and instantly visibly informative and helpful, and not duplicated:

   The.Amazing.Race_WCCODT_.S33E03.Who.Has.This.One.in.the.Bag.ts
   The.Amazing.Race_USAHD_.S33E03.Who.Has.This.One.in.the.Bag.ts

How has adding the station ID broken anything? Seems to me it's helped, not hurt, to guarantee uniqueness... if that were even relevant?

I am asking for it to be informative and useful when looking at folder contents on your computer, with Explorer, having nothing to do with how beautiful things look when using NextPVR on your TV.

Oh well.

[DSperber]

Well, I'm sorry to bring this thread and topic back to life, but I'm working through an issue involving uiDroid being able to play Live TV just fine, but being unable to play recordings (on both Shield Tube as well as Xiaomi Stick 4K). I'm not quite there yet in terms of finally getting a recording to play successfully, but I believe the underlying problem is how the recordings were made in the first place. And this further involves (a) file naming and folder/sub-folder structure, as well as (b) whether the recording DVR server was running in Win7 or Win10, with both configured to point to the same common "high-level parent recording folder".

So, once again, it turns out that while a product as simple and archaic as Windows Media Center always just simply dynamically builds a new index of recordings then discovered to be present in its own recording folder(s) whenever the client app is launched, that is NOT the way NextPVR works.  So apparently you can't just create folder/file structures within the NextPVR parent folder and populate them with the correct TS and XML files that truly were created by a true recording event. They apparently will not simply be auto-detected when the NextPVR client is launched and Recordings is examined.

I'm sure this is at the heart of the problem as to why uiDroid CANNOT play the recordings that it shows listed correctly, but official NextPVR client CAN play the same recording also listed correctly.

Now when last we interacted here on this thread, I had gone ahead and moved to "Plex file naming" -> TRUE, in order to insert the season/episode within the file name.



This still didn't insert the station ID in the file name, but theoretically it would insert SxxxEyyy which would help me when just browsing the folder manually using Explorer.

So today, as part of my ongoing chasing down of the uiDroid recording-playback issue I decided to boot to Win10 (I had previously been in Win7 and running NextPVR server that way), in order to do everything in Win10... just to be current and consistent. I also made sure I absolutely was at the very latest NextPVR server/client, and in fact have now upgraded from 5.2.6 up to 5.2.7.

I then looked at Recordings, expecting to see the three recordings I'd made yesterday (but while under Win7). Imagine my surprise when I didn't see any of them, but instead saw several old recording of shows I'd created back in January (when last I was playing with NextPVR and experimenting with uiDroid). I then looked at my recording folder (commonly named in both Win7 and Win10 NextPVR setup), and saw just the files I'd recorded yesterday while in Win7. The recording files currently named in the Win10 client I just launched were gone (obviously due to my own improper manual interference and actions and "cleaning house" foolishly).

So the Win10 NextPVR client showed supposedly existing recordings (obviously still named in some other "recordings" file somewhere that I know not what or where), that don't exist. And the files that are there which were created by Win7 yesterday most likely do not conform to the folder/file structure implied by my Win7 version of config.xml. I think I was previously experimenting with eliminating the season and show-name folder structure and just putting everything into one large single folder (a la WMC) in Win7, but it looks like I never implemented that same change in Win10. In fact I can't even remember now how I did it in Win7 (but I could find it if I looked hard enough).

Ok. I just decided to forget about whatever I did yesterday in Win7. I deleted all the recording files present as shown in the Win10 NextPVR client list (and which no longer existed on disk), deleted the recording files made yesterday while in Win7 from the recordings folder (and which never appeared in the Win10 NextPVR client list of recordings when I launched it), and with everything now "empty" started all over from scratch in Win10. I went to NextPVR Guide, and decided to record 5 minutes of the news program currently playing on KTLADT (5) which is ATSC 1.0, and also its counterpart being broadcast on KTLA HD (105) which is ATSC 3.0. This would probably be useful input to chase down the uiDroid issue (assuming it just didn't automatically start working properly once I got the recordings folder contents straightened out to meet its expectations).

Here then is the result of those two simultaneous recordings:

(1) Contents of the recording folder (note that even though file naming is Plex-format, this is just a date-oriented show with no SxxxEyyy to be inserted, so there is only the ordinary date and time suffix, AND NO STATION ID in the external file name to distinguish which file is from KTLADT and which file is from KTLA HD):



(2) Here is what NextPVR -> Recordings presents (note only one program name, because the Guide title is identical for both the ATSC 1.0 and ATSC 3.0 broadcasts):



(3) And when I drill down into this one recording title to see all sub-files (i.e. season/episodes, date-based, etc.) I see this (note, finally there is the recording's originating station ID shown next to each individual recording... which is what I'm pleading for on this thread, if only this information which is clearly known could simply be inserted into the external file name and be done with it!!!):



Of course I can in fact play BOTH of these recordings just fine using the Win10 NextPVR client app. Of course there's no sound from the 105 recording (ATSC 3.0) but that's expected.

Anyway, I am now about to move over to both NextPVR client app and uiDroid client app, running on both Shield Tube and Xiaomi Stick 4K, to see if they can now all play these brand newly made recordings from Win10 NextPVR server. Certainly the folder/file structure produced just now is different from the way things looked yesterday when I made my three test recordings while in Win7 NextPVR server. There's no season/episode info in these new recordings (even though file names are supposed to be in Plex-format), but we shall see what happens.

Nevertheless... no matter how much you beat on me, I maintain that the [optional by config.xml setting is fine with me] facility for automatic insertion by NextPVR of recording station ID into the external file name (say as optional and ignored "suffix data", so as not to break anything) would be very helpful in just physically doing a manual browse of folder/file things using Explorer. It breaks nothing, has zero impact on file name uniqueness, and is only useful and helpful information.

No need for any unnecessary post-processing (which I never could understand how to actually implement from the many writeups I attempted to read and follow) or Extra stuff or anything. Just put the station ID in the external file name (say always at the very end), like WMC does. Very useful and informative by being there when using Explorer. It's obviously already present in the "recording catalog data of files", so it's nothing new that needs to be gathered. Just inserted into the file name.

It is not redundant of the same information shown in anything else external that is currently being create. Not currently shown in any folder or file name. But clearly present in the "catalog of recordings" as it is presented on that drill-down lowest levei list of individual recordings for a program title.

[mvallevand]

On topic I provided you with a utility to do your custom renaming, but if you don't want to use it that is fine. Most people don't use real clients not the file system, and with AC-4 files you don't have much choice

On the topic of the AC-4 files all that unnecessary information above doesn't help when really all I need is the logs and a sample recording with xml file. Your KTLA file look perfect.

Martin

[DSperber]

On topic I provided you with a utility to do your custom renaming, but if you don't want to use it that is fine. 

Martin

Not exactly "provided you with a utility". Had it been something I could have actually followed step-by-step and that actually matched my goals and objectives, I would have certainly attempted it and learned from it

However what you actually provided was:

"Brett's reference to custom naming using batch files and NSCripthelper https://github.com/sub3/NextPVR/wiki/nscripthelper might be of value..."

With all respect and appreciation for your attempt to guide me in the right direction, I found this to be incomprehensible. I was also unable to fathom how to initiate a "post-processing script", as none of the writeups and examples were simple and clear and specific, at least not for me as a FIRST-TIMER trying to use NextPVR and doing something not absolutely default.

None of any writeup or article I read about "post-processing" showed me anything I could actually use, much less then try to invent my own "custom naming batch file" in order to insert that channel ID value as I want. If there actually were a single place where this precise project was implemented by someone, starting from step 1 and going to step N, I would attempt it. But otherwise, I'm sorry I'm not the programmer who apparently these articles are all intended for.

And bottom line, I honestly do NOT feel this should be only available through some complex programming and customization method. The ability to insert season/episode into file names apparently was felt important enough to be implemented through a simple config.xml variable "UsePlexStyleNaming". I know it is SUB that this is really being directed to, but it's essentially that request, to add one additional config.xml variable "InsertChannelID" to provide this additional file naming option to the user.

And though my feelings have obviously been expressed numerous times already, personally I feel that channel ID responsible for the TS/XML recording files is VERY APPROPRIATE information to include in the external file name, certainly no less appropriate than recording date and time which is there right now (to identify and distinguish, for anybody browsing the folder using Explorer, for no other reason really since like channel ID the date/time is ALSO present elsewhere in the "catalog of recordings" so that it is displayed when you drill-down to see details for one or more occurrences of a recording title).

Still haven't made it over to Shield/Xiaomi devices yet to confirm that both NextPVR and uiDroid running on both devices can, in fact, now play recordings without a problem, now that the folder/file structure are in sync with the "recordings catalog", all created correctly from scratch with Win10 server. But that discussion is to be continued over on my other thread.