Hi,
the current folder setting feature for timers doesn't have easy way to reset the selected folder back to the root one - or I just missed it. I'd really like to see this little addition in the next vdr release.
BR, -- rofa
On 03.02.2010 16:02, Rolf Ahrenberg wrote:
Hi,
the current folder setting feature for timers doesn't have easy way to reset the selected folder back to the root one - or I just missed it. I'd really like to see this little addition in the next vdr release.
Well, you can always position to the file name, pres "Right" and then "Yellow" to delete the folder part of the name.
Klaus
On Wed, 3 Feb 2010, Klaus Schmidinger wrote:
Well, you can always position to the file name, pres "Right" and then "Yellow" to delete the folder part of the name.
Yes, but IMO that's not an easy way. :) I was thinking about a special root directory entry for folders.conf.
BR, -- rofa
On 04.02.2010 08:17, Rolf Ahrenberg wrote:
On Wed, 3 Feb 2010, Klaus Schmidinger wrote:
Well, you can always position to the file name, pres "Right" and then "Yellow" to delete the folder part of the name.
Yes, but IMO that's not an easy way. :) I was thinking about a special root directory entry for folders.conf.
How about '.'? (w/o the single quotes). That would result in /video/./name, which is the same as /video/name.
Klaus
On Fri, 5 Feb 2010, Klaus Schmidinger wrote:
How about '.'? (w/o the single quotes). That would result in /video/./name, which is the same as /video/name.
That was my initial idea too, but due to the VFAT conversion a '#2E' sub-directory will be made instead of the root directory. I'm using this same cMenuFolder class in my rename recordings patch, but the same problem should exist in the vanilla timers edit menu too.
BR, -- rofa
On 05.02.2010 23:43, Rolf Ahrenberg wrote:
On Fri, 5 Feb 2010, Klaus Schmidinger wrote:
How about '.'? (w/o the single quotes). That would result in /video/./name, which is the same as /video/name.
That was my initial idea too, but due to the VFAT conversion a '#2E' sub-directory will be made instead of the root directory. I'm using this same cMenuFolder class in my rename recordings patch, but the same problem should exist in the vanilla timers edit menu too.
Well, the "problem" only exists if you use that dreaded VFAT stuff ;-)
So what about treating the special folder name "/" (w/o the quotes) as "no folder"?
Klaus
Hi, Just my opinion about the problem: The fat filesystem has many limitations and I vote for dropping special support for it in VDR because if someone wants to use a windows system, he/she can use ntfs which works fine in current distributions (ntfs-3g). Just my 2 Cents. Halim
On 06.02.2010 12:27, Halim Sahin wrote:
Hi, Just my opinion about the problem: The fat filesystem has many limitations and I vote for dropping special support for it in VDR because if someone wants to use a windows system, he/she can use ntfs which works fine in current distributions (ntfs-3g). Just my 2 Cents.
I would do that in a heartbeat - but I guess that would cause a huge flame war... ;-)
Klaus
On Sat, 6 Feb 2010, Klaus Schmidinger wrote:
On 06.02.2010 12:27, Halim Sahin wrote:
Hi, Just my opinion about the problem: The fat filesystem has many limitations and I vote for dropping special support for it in VDR because if someone wants to use a windows system, he/she can use ntfs which works fine in current distributions (ntfs-3g). Just my 2 Cents.
I would do that in a heartbeat - but I guess that would cause a huge flame war... ;-)
Without VFAT-option I encountered huge problems with my Samba shares and FAT32 formatted USB sticks, so I'm against dropping this feature. :)
Anyway back to real problem, my original idea was to add an extra "/" cMenuFolderItem object into NestedItemList in cMenuFolder constructors, or you could always easily assign a new key short cut to reset the folder (i.e. k0).
BR, -- rofa
On 06.02.2010 17:13, Rolf Ahrenberg wrote:
On Sat, 6 Feb 2010, Klaus Schmidinger wrote:
On 06.02.2010 12:27, Halim Sahin wrote:
Hi, Just my opinion about the problem: The fat filesystem has many limitations and I vote for dropping special support for it in VDR because if someone wants to use a windows system, he/she can use ntfs which works fine in current distributions (ntfs-3g). Just my 2 Cents.
I would do that in a heartbeat - but I guess that would cause a huge flame war... ;-)
Without VFAT-option I encountered huge problems with my Samba shares and FAT32 formatted USB sticks, so I'm against dropping this feature. :)
Anyway back to real problem, my original idea was to add an extra "/" cMenuFolderItem object into NestedItemList in cMenuFolder constructors, or you could always easily assign a new key short cut to reset the folder (i.e. k0).
'0' is already used to switch the day between "one time" and "repeated".
To be honest, I didn't even think of removing the folder being such an "every day" operation. I thaught you would normally have a list of folders, and when you define a timer, it first goes into the video directory without a folder. Then when you decide to put it into a folder, you select one and that's it. If you really want to go back to the plain video directory, you can always delete the folder part from the file name. But that's something that would normally happen only very rarely, I guess.
Klaus
Klaus Schmidinger wrote:
On 06.02.2010 12:27, Halim Sahin wrote:
Hi, Just my opinion about the problem: The fat filesystem has many limitations and I vote for dropping special support for it in VDR because if someone wants to use a windows system, he/she can use ntfs which works fine in current distributions (ntfs-3g). Just my 2 Cents.
I would do that in a heartbeat - but I guess that would cause a huge flame war... ;-)
...and you would loose the ability to use vanilla USB sticks. Bad idea.
Oliver
On Sat, Feb 6, 2010 at 3:27 AM, Halim Sahin halim.sahin@t-online.de wrote:
Hi, Just my opinion about the problem: The fat filesystem has many limitations and I vote for dropping special support for it in VDR because if someone wants to use a windows system, he/she can use ntfs which works fine in current distributions (ntfs-3g). Just my 2 Cents. Halim
Forcing people to change their servers by dropping _already existing_ support doesn't seem like the best way to handle it? There may be reasons they can't/don't use ntfs, though I'd rather not speculate what-if's. Another option could be to take a poll and if it's obvious dropping fat support isn't such a big deal, then bye bye fat.
-
Halim Sahin -
Klaus Schmidinger -
Oliver Endriss -
Rolf Ahrenberg -
VDR User