Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[tzr916]

Is there some technical reason why:

-Whenever MC records a Tv show that has a long file name, it also creates a Time Shift folder.
-If I try to delete the Tv show (in Theater View), an error comes on the screen and I have to "try again". The TS file deletes, but the time shift folder (and all files inside) does NOT delete.

Some example file names:
Jimmy Kimmel Live - Chris Pratt; Kurt Russell; Zoe Saldana; Dave Bautista; Michael Rooker; Bleachers 2017-04-17

The Tonight Show Starring Jimmy Fallon - S2017E658 - Bob Odenkirk; Lucy Hale; Robert Irwin; Brad Paisley; Dweezil Zappa


I've tried telling MC to chop the file name, but then it looses all of it's details - episode number, description, etc.

[muzicman0]

Same thing happens if a show name end with '...'.  IE: 'Limitless - S01E20 - Hi, My Name Is Rebecca Harris ...'.

The folder won't delete.  I did find a work around for that situation, and it is documented here:

http://yabb.jriver.com/interact/index.php/topic,104411.0.html

It would be nice if JRiver would put some logic in before creating folders to determine if it is a legal folder name or not.

[Yaobing]

Is there some technical reason why:

-Whenever MC records a Tv show that has a long file name, it also creates a Time Shift folder.

It is not the long file name that caused MC to create a time-shifting folder.  We always do.  It is just the long file name prevented the folder from being deleted.

When you record in TS format, we simultaneously keep a time-shifting folder with all the time-shifting files in it, so that we can view the show any time the recording is still going on.

I've tried telling MC to chop the file name, but then it looses all of it's details - episode number, description, etc.

If the episode number and description are in EPG data, we save them to MC database, and we output them to the recording's sidecar file.  So the information is not lost.

I think Windows 260 character rule for file paths is biting us here.  I don't understand why we can create the file but can not delete the file.

Same thing happens if a show name end with '...'.  IE: 'Limitless - S01E20 - Hi, My Name Is Rebecca Harris ...'.

The folder won't delete.  I did find a work around for that situation, and it is documented here:

http://yabb.jriver.com/interact/index.php/topic,104411.0.html

It would be nice if JRiver would put some logic in before creating folders to determine if it is a legal folder name or not.

Thanks for providing a solution.  You provided another example of file name problems ('...').  I also had a file who's name ended with a space.  And that one could not be deleted.

It is easier to solve problems like "..." or " " in the file name.  We just have to remove them.  If the problem is caused by file name being too long, the only way to solve it probably is to truncate the file name.  That definitely will make using file name as information carrier not working.

[Yaobing]

This is probably also the explanation why I could not clean up a couple of folders with "Steve Harvey" shows.  The folder name and the file name inside the folder are both over 120 characters.  Adding "H:\Video\TV Recordings\" puts it over 260.

[tzr916]

It is not the long file name that caused MC to create a time-shifting folder.  We always do.  It is just the long file name prevented the folder from being deleted.

When you record in TS format, we simultaneously keep a time-shifting folder with all the time-shifting files in it, so that we can view the show any time the recording is still going on.

Ya, I knew this. But these long file name folders remain after the recordings are finished, like the next morning. Then I have to manually delete the folders from windows explorer (locally or network drive access). I end up cleaning up several of these folders once a week.....

If the episode number and description are in EPG data, we save them to MC database, and we output them to the recording's sidecar file.  So the information is not lost.

I don't think there is a sidecar when recording TS. So trying to modify the filename in the recording options just makes episode, description, etc. empty.

[Yaobing]

I don't think there is a sidecar when recording TS. So trying to modify the filename in the recording options just makes episode, description, etc. empty.

Sidecar file for video is configured at Tools > Options > General > Importing & Tagging > Store tags in external sidecar file...

[tzr916]

More and more folders being created that are impossible to delete. Using clean up time shift in MC does not do it, Admin take ownership does not do it- says folder no longer exists in location. I've accumulated 21 empty folders since installing the latest MC version and they won't delete.

[muzicman0]

It's not a long file name, it's that the folder ends with '...'.  See my post above for a link to a solution.

[tzr916]

Correct, but MC latest version is now purposely putting in the "..." to supposedly try to avoid this very issue. Doesn't seem to be working.

Sent from my XT1585 using Tapatalk

[JimH]

Sent from my XT1585 using Tapatalk

Please turn this off.

[muzicman0]

Correct, but MC latest version is now purposely putting in the "..." to supposedly try to avoid this very issue. Doesn't seem to be working.

Really??  They are purposefully adding an ellipse at the end of a folder?  That should be changed immediately, as that is not a legal folder name.

[Yaobing]

Correct, but MC latest version is now purposely putting in the "..." to supposedly try to avoid this very issue. Doesn't seem to be working.

It is not what we recently did that added the ..., probably some older code.  I will check.

By the way, it looks like you are using extremely long paths. Is there a reason for this?

[tzr916]

By the way, it looks like you are using extremely long paths. Is there a reason for this?

I was just viewing the folder via a networked machine (simple windows sharing/access). The recorded tv folder is a first level folder on a dedicated local sata drive in the server.

[RoderickGI]

You are correct tzr916. Long folders that have been shortened are definitely now getting a "..." added to the end. This is absolutely the wrong thing to do, as Windows allows you or a program to create such a directory, but does not allow you to delete it, as it can't find the folder. Windows can't interpret the "..." correctly, since a "." defines, or should define an extension.

Yaobing,there was an additional change in 107;

22.0.107 (5/16/2017)

1. Changed: Minor change in how television time-shifting folder length is shortened as introduced in build 106.

on top of the earlier changes;

22.0.106 (5/1/2017)

1. Fixed: Television time-shifting files with long file paths were not cleaned after time-shifting/recording sessions ended.
2. Fixed: Cleanup time-shifting folders tool could not clean up files with long file paths.
3. Fixed: Media Center might not have output 32 channels reliably.
4. Fixed: A bug in television time-shifting index file handling that caused problems when show names were super long.
5. Fixed: "Rename, Move, & Copy file" did not format new file name correctly for files with long file paths.
6. Fixed: JTV files could not be renamed or copied correctly if they had long file paths.
7. Changed: Folder name length of television time-shifting folder (for each time-shifting or recording session) is limited to 50 characters or fewer, to reduce the chance of having super long jtv file paths (some TV show's name field may be over 100 characters long).

Could someone have snuck in a "this will look better" change in 107 that you didn't know about? It certainly looks like it is new functionality based on my folder names, and the timing of their creation. It is usual to add a "..." suffix when a name or other text is shortened. Someone may have been too smart for their own good, or ours!

Please consider this a "must be fixed in MC22" bug, as it will result in an awful lot of folders being created that can't be deleted. Thank you.

[JimH]

We will look at this today.  Thanks for reporting the details.

[Yaobing]

Yaobing,there was an additional change in 107;

on top of the earlier changes;

This last change did not add ... at the end either.  "..." at end must be some older code.  However, I did add "..." in the middle of a truncated folder name (not at end).  Windows should be able to interpret '.' in a file name or folder I think, maybe not at the end.

[Yaobing]

Someone may have been too smart for their own good, or ours!

That was me. 

The problem was not the ellipsis, it was the extra space after the ellipsis.

Fixed: A bug in recent builds that would cause TV time-shifting folder name to end with a space and such folder could not be deleted.
Fixed: TV Recording clean up tool could not remove the malformed folder that had a folder name that ended with a space.

When the fixed version is out, you should be able to delete those bad folders already created too.

[muzicman0]

You can't end a folder with an ellipse either, so if it is still creating those, it will still be a problem.

[Yaobing]

Now we will not end with ...

[muzicman0]

Awesome!

[RoderickGI]

That was me. 

That is okay Yaobing, you more than made up for it with your fix.

Simply installing MC22.0.110 renamed all the directories MC knew about I had that ended in "... ". I had to double check, because I couldn't find most of the problem directories immediately after the install. No user intervention required. Very nicely done.

All the directories were nicely renamed into the form "Spicks and Specks - Sharon Jones, Fe... 2017-06-02", so the "... " will always be before the end of the directory name. I note that the space is still in there, which is fine.

I still had one problem directory that was already empty, as MC had deleted the contents, but couldn't delete the directory. Of course, MC no longer knew about that directory so it wasn't renamed. However, simply running the "Cleanup time-shifting folders" tool found and deleted that last directory. Although it didn't report the deletion along with the other things it fixed, I'm not concerned about that. Again, very nicely down.

So you are redeemed Yaobing. A very thoroughly thought out and complete fix. 

[JimH]

A very thoroughly thought out and complete fix.

That's a perfect description of Yaobing's work, in general.

[Yaobing]

That is okay Yaobing, you more than made up for it with your fix.

You appear to give me more credit than I deserve.  There is no automatic renaming.  My assumption is that the recordings that in such folders still can be played.  The problem is only when you try to delete them (or when time-shifting session ends).

If your naming rule is to include a date (which is the default behavior), then the ellipsis is always before the date, even before today's fix.  The problem arises only if you do not have the date part.

I did make sure today that manual clean up will remove the bad folders that previously could not be removed.  So if you have those folders that have "... " at the end of folder name, you can just run the cleanup tool.

[RoderickGI]

You appear to give me more credit than I deserve.  There is no automatic renaming.  My assumption is that the recordings that in such folders still can be played.  The problem is only when you try to delete them (or when time-shifting session ends).

Oh? Oh! Yes, recording can be played. Correct.

I was pretty sure that I had half a dozen recent recording directories with a "... " at the end, but maybe because they were all the same length, and I was looking at them in Windows Explorer, the dates just looked like the file date column. I can easily see the difference now though. Unfortunately I didn't take a screenshot, and now hey all have the date suffix.

Normally I am more careful than that. Sorry.

If your naming rule is to include a date (which is the default behavior), then the ellipsis is always before the date, even before today's fix.  The problem arises only if you do not have the date part.

Naming rule? Have I missed something? I'm just letting MC do the naming. No filename/path tagging rules in the Recording Rule tagging dialogue. I assume the date at the end was added at some stage, because I have quite a number of recent recording folders that do not have the date at the end of the name. The most recent is May 31st.

What I did notice though is that directories that didn't have a date suffix are all from a few recording rules which haven't been updated for some time. Could it be that a Recording Rule edit is required to fully implement (add the date suffix) the directory length change from MC22.0.106 for that rule? I have now edited all my rules, and will see in the next few days if all recording directories now get a date at the end.

I had to rescan my channels recently (a couple of weeks ago), with some channels being replaced with new ones, and others deleted. This means that MC picked up new TV Channel Identifiers for a number of channels. I edited the Recording Rules which were affected by the change, and those recording directories all have the date suffix. Hence, my question about needing to edit the rules to have some change take effect.

I did make sure today that manual clean up will remove the bad folders that previously could not be removed.  So if you have those folders that have "... " at the end of folder name, you can just run the cleanup tool.

Yep, works well.


Regardless of how much you actually did, great effort in getting a fix out so quickly. Thank you.

[Yaobing]

By naming rule, I meant the Filename(name) tagging.  If you did not set it, then you use default.  I check the code.  It turns out, for default file name rule, we do not use date suffix if a show has episode number.  With episode number the file name should be pretty much uniquely identified using episode number.  I use PercData for EPG which does not have episode numbers.  That is why all my recordings do have date in filename.  This was the source of my trouble.  I did not remember how it was supposed to work, and assumed we always had date at the end. 

[RoderickGI]

Okay, that is consistent with the programs I have that don't have a date suffix. They all have Season and Episode numbers, which is included in the file and directory names of my JTV recordings.

Part of the mystery solved then.