Mailing List Archive

On Fri, 10 Mar 2023 11:39:20 -0600, you wrote:

>All,
>
> ? I have about 300G in SSD space and several TBs in spinning disk
>RAID1. Currently, I do not use SSD for recording at all, as it is very
>small compared to HDs. Is it possible to add the SSD to storage
>directory and somehow make mythtv use it like a cache? I can write small
>cron job? to balance the contents overnight so that only recent
>recordings are present in SSD.? The only question is how do I tell
>mythtv to use only SSD for new recordings as much as possible?
>
>It appears that most of the storage management methods in mythtv are
>focused on distributing recordings based available space rather than the
>type of storage or user preferred targets. Can I do something better? I
>put all spinning disks in one storage group and SSD in default storage
>group. I manage moving files overnight (or more frequently) to keep the
>balance. This seems like a possibility.
>
> 1. What happens if SSD fills up? Does mythtv automatically go to
> another storage group to record the new show even if the recording
> rule says "default" is the storage group?

No, it will delete from the SSD to create space. The recording rule
for each recording tells which storage group to use. But I believe
MythTV is not selective when it comes to keeping the minimum storage
space available on all recording storage groups - if any storage group
falls below the minimum setting (around 20 Gibtyes), recordings will
be deleted to get it back over the minimum, even if that storage group
is not actually being used to record to. So you have to be careful
when a destination drive is getting full that you do not copy a file
that would take the free space below that limit. If you do, shortly
after that MythTV will delete recordings from that drive until its
free space is above the limit again. Even if that drive is never used
directly for recording to, as long as it is in a storagegroup other
than one of the special ones (eg music, pictures), it will always have
recordings deleted to keep its free space above the limit.

> 2. Also, what happens when my script tries to move a file from SSD to
> HD and in the process there are duplicate copies of the same file in
> multiple storage directories when I trigger a lookup/watch from a
> frontend?

You need to make sure your script does not create duplicates. You do
that by copying to temporary file names (eg add .tmp on the end). Then
delete the original recordings and rename the .tmp files to the
correct name.

> 3. Even worse, what happens when a file moves from SSD to HD while I am
> watching a show?

Do not do that, if possible. It may sort of work, as I believe that
when Linux attempts to delete a file that is in use, it will not
delete it immediately but will wait until it is no longer in use. But
the ancillary files (.png screenshot files, for example), will not be
in use and then will be on a different drive from the corresponding
.ts file. And you may wind up with two copies of the .ts file until
the original gets deleted, if it does actually get deleted.

In my mythsgu Python program where I move recordings from my 7
recording drives to my (currently 6) offline archive drives, I have
put a lot of work into deciding whether MythTV is busy and only moving
files when it is not. If it suddenly becomes busy, the file being
moved gets its copying paused (or cancelled) until MythTV is idle
again. It does that using several different techniques. Firstly, it
looks at the inuseprograms table in the database. If that table is
not empty, MythTV is busy. Second, it looks at the upcoming
recordings list, and stops doing things well before the next scheduled
recording time. Thirdly, it traps all event messages and whenever it
sees one, re-evaluates the busy status.

http://www.jsw.gen.nz/mythtv/mythsgu

See the "mythsgu fill" and "mythsgu pack" commands for the relevant
code.

Note that mythsgu was originally written a long time ago in Python 2
and has been converted to Python 3. It uses the now obsolete asyncore
package to do asynchronous operations, and asyncore is now deprecated
and will be removed shortly, so I need to rewrite it to use asyncio.

I am not sure why you feel the need to have recordings go to your SSD.
As long as hard drives are spinning at the time, starting a recording
or playback is very fast and there is not much gained by using an SSD.
And recording such huge amounts of data to any SSD will drastically
shorten its lifetime and you will have to be replacing it often. And
making sure you have proper monitoring and notification as it reaches
the end of its lifetime. SSDs these days usually have a specification
for their lifetime in "terrabytes written" (TBW). That should make it
fairly easy to estimate the lifetime based on how many Gbytes you
write to recordings every day - all other use will be minimal compared
to that traffic.

If you are finding that you are recording too many things at once and
your hard drives can not cope, then you should probably just add
another recording hard drive. Each hard drive will be able to record
at least two recordings at once and probably three. Using RAID1
means, of course, that you would need to add two drives. Most of us
do not bother with RAID for recordings.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 3/10/23 21:32, Stephen Worthington wrote:
> On Fri, 10 Mar 2023 11:39:20 -0600, you wrote:
>
>> All,
>>
>>   I have about 300G in SSD space and several TBs in spinning disk
>> RAID1. Currently, I do not use SSD for recording at all, as it is very
>> small compared to HDs. Is it possible to add the SSD to storage
>> directory and somehow make mythtv use it like a cache? I can write small
>> cron job  to balance the contents overnight so that only recent
>> recordings are present in SSD.  The only question is how do I tell
>> mythtv to use only SSD for new recordings as much as possible?
>>
>> It appears that most of the storage management methods in mythtv are
>> focused on distributing recordings based available space rather than the
>> type of storage or user preferred targets. Can I do something better? I
>> put all spinning disks in one storage group and SSD in default storage
>> group. I manage moving files overnight (or more frequently) to keep the
>> balance. This seems like a possibility.
>>
>> 1. What happens if SSD fills up? Does mythtv automatically go to
>> another storage group to record the new show even if the recording
>> rule says "default" is the storage group?
> No, it will delete from the SSD to create space. The recording rule
> for each recording tells which storage group to use. But I believe
> MythTV is not selective when it comes to keeping the minimum storage
> space available on all recording storage groups - if any storage group
> falls below the minimum setting (around 20 Gibtyes), recordings will
> be deleted to get it back over the minimum, even if that storage group
> is not actually being used to record to. So you have to be careful
> when a destination drive is getting full that you do not copy a file
> that would take the free space below that limit. If you do, shortly
> after that MythTV will delete recordings from that drive until its
> free space is above the limit again. Even if that drive is never used
> directly for recording to, as long as it is in a storagegroup other
> than one of the special ones (eg music, pictures), it will always have
Do you mean mythtv will delete files even if they are not marked to be
deleted? I expect that it will not record any new shows when disk is
full. Deleting a recording that I want to keep is not very user
friendly.  I never had this happen as I always had enough space. May be
I never had to deal with it and therefore assumed this never happens.
> recordings deleted to keep its free space above the limit.
>
>> 2. Also, what happens when my script tries to move a file from SSD to
>> HD and in the process there are duplicate copies of the same file in
>> multiple storage directories when I trigger a lookup/watch from a
>> frontend?
> You need to make sure your script does not create duplicates. You do
> that by copying to temporary file names (eg add .tmp on the end). Then
> delete the original recordings and rename the .tmp files to the
> correct name.
>
>> 3. Even worse, what happens when a file moves from SSD to HD while I am
>> watching a show?
> Do not do that, if possible. It may sort of work, as I believe that
> when Linux attempts to delete a file that is in use, it will not
> delete it immediately but will wait until it is no longer in use. But
> the ancillary files (.png screenshot files, for example), will not be
> in use and then will be on a different drive from the corresponding
> .ts file. And you may wind up with two copies of the .ts file until
> the original gets deleted, if it does actually get deleted.
>
> In my mythsgu Python program where I move recordings from my 7
> recording drives to my (currently 6) offline archive drives, I have
> put a lot of work into deciding whether MythTV is busy and only moving
> files when it is not. If it suddenly becomes busy, the file being
> moved gets its copying paused (or cancelled) until MythTV is idle
> again. It does that using several different techniques. Firstly, it
> looks at the inuseprograms table in the database. If that table is
> not empty, MythTV is busy. Second, it looks at the upcoming
> recordings list, and stops doing things well before the next scheduled
> recording time. Thirdly, it traps all event messages and whenever it
> sees one, re-evaluates the busy status.
>
> http://www.jsw.gen.nz/mythtv/mythsgu
>
> See the "mythsgu fill" and "mythsgu pack" commands for the relevant
> code.
>
> Note that mythsgu was originally written a long time ago in Python 2
> and has been converted to Python 3. It uses the now obsolete asyncore
> package to do asynchronous operations, and asyncore is now deprecated
> and will be removed shortly, so I need to rewrite it to use asyncio.
>
> I am not sure why you feel the need to have recordings go to your SSD.
> As long as hard drives are spinning at the time, starting a recording
> or playback is very fast and there is not much gained by using an SSD.
> And recording such huge amounts of data to any SSD will drastically
> shorten its lifetime and you will have to be replacing it often. And
> making sure you have proper monitoring and notification as it reaches
> the end of its lifetime. SSDs these days usually have a specification
> for their lifetime in "terrabytes written" (TBW). That should make it
> fairly easy to estimate the lifetime based on how many Gbytes you
> write to recordings every day - all other use will be minimal compared
> to that traffic.
>
> If you are finding that you are recording too many things at once and
> your hard drives can not cope, then you should probably just add
> another recording hard drive. Each hard drive will be able to record
> at least two recordings at once and probably three. Using RAID1
> means, of course, that you would need to add two drives. Most of us
> do not bother with RAID for recordings.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums:https://forum.mythtv.org
Ok, it looks like mythtv is not really setup for this type of dynamic
movement.  I had no intention of doing any dyncamic movement, but was
asking just to see what is possible. I only had plans to rebalance at
2am when I know nothing is being recorded or watched.

After reading through your response, I do not think I will attempt to do
anything to add the SSD. Typically, my SSDs get so under utilized that
they never wear out. I thought this will balance out when I get the urge
to upgrade due to size.

I have one machine that is always on. So, I run everything on it. It is
my backup machine as well as a front & backend. Thus it has a lot of
storage and RAID to be failure tolerant.

Regards
Ramesh

On 11/03/2023 05:53, Ram Ramesh wrote:
> Do you mean mythtv will delete files even if they are not marked to be
> deleted? I expect that it will not record any new shows when disk is
> full. Deleting a recording that I want to keep is not very user
> friendly.  I never had this happen as I always had enough space. May be
> I never had to deal with it and therefore assumed this never happens.

MythTV will only auto-delete recordings that have been set to
auto-expire. So probably when discussing this functionality we should
use that word: auto-expire.

Each recording rule contains a flag that determines whether the
recordings carried out under it will be marked to auto-expire. But you
can also individually set or clear the auto-expire flags on already-made
recordings.

There's a brief write-up on the wiki here: [1].

[1]: https://www.mythtv.org/wiki/Using_MythTV#How_MythTV_Records

HTH, Jan

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 11/03/2023 03:32, Stephen Worthington wrote:
>
(snip)
>
> I am not sure why you feel the need to have recordings go to your SSD.
> As long as hard drives are spinning at the time, starting a recording
> or playback is very fast and there is not much gained by using an SSD.

One potential problem would be that most very large modern HHDs are shingled; I read that this makes
reads quick but writes much slower, as it has to rewrite a whole track every time anything on that
track changes. This might be a reason to use an SSD as a 'cache'.

I have no numbers to hand to say whether the above is still true, or whether the inbuilt RAM cache
in the drive is large enough to soak up the required write rate.

> And recording such huge amounts of data to any SSD will drastically
> shorten its lifetime and you will have to be replacing it often. And
> making sure you have proper monitoring and notification as it reaches
> the end of its lifetime. SSDs these days usually have a specification
> for their lifetime in "terrabytes written" (TBW). That should make it
> fairly easy to estimate the lifetime based on how many Gbytes you
> write to recordings every day - all other use will be minimal compared
> to that traffic.
>

Absolutely! One thing that is certain is that every SSD will eventually fail once it reaches its
write limit - which may or may not be what the manufacturer thinks (or says) it is. And the failure
mode is sudden and total. Take regular backups!

With a spinning HDD a failure to write may mean the disk has to be replaced but it is usually
possibly to pull most if not all of the data off it. I have HDDs in some of my hosts that are 10-12
years old and still performing well.

I will add that I do not rely on those disks, they are always well backed up or are easily
replacable with a fresh install on a spare drive.

--

Mike Perkins


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sat, 11 Mar 2023 10:13:30 +0000, you wrote:

>On 11/03/2023 03:32, Stephen Worthington wrote:
>>
>(snip)
>>
>> I am not sure why you feel the need to have recordings go to your SSD.
>> As long as hard drives are spinning at the time, starting a recording
>> or playback is very fast and there is not much gained by using an SSD.
>
>One potential problem would be that most very large modern HHDs are shingled; I read that this makes
>reads quick but writes much slower, as it has to rewrite a whole track every time anything on that
>track changes. This might be a reason to use an SSD as a 'cache'.
>
>I have no numbers to hand to say whether the above is still true, or whether the inbuilt RAM cache
>in the drive is large enough to soak up the required write rate.

You can never use a shingled drive for MythTV recording, as the Linux
and MythTV buffers combined are far too small to allow for writing to
the disk to stop for up to 60 seconds as can happen. So for MythTV
use, you need to record to an ordinary CMR drive and afterwards you
can move the recording files to a shingled drive. Four of my archive
drives are shingled and I wrote mythsgu as a way to automate my file
moves to the archive drives. When I got my first shingled archive
drive, I had to update the kernel for it to work properly - older
kernels just timed out when a shingle rewrite happened.

But it is incorrect to say that most very large modern HDDs are
shingled. If you are a data centre or massive corporation, the sales
people will offer you those options, but most retail sites do not even
list those sorts of drives as they require the operating system do the
shingle operations, rather than the drive doing them automatically.
There are consumer oriented shingled drives available, usually in the
Red/NAS type drives, where the drive does the shingled operations
automatically, and all you see from the operating system is that a
write operation stalls for a very long time. Operating systems now
cope with that stall situation rather than timing out and saying the
write failed. My shingled archive drives are of this latter type. It
used to be that the largest drive I could buy was a shingled one, but
quite some margin, but that has changed over the last few years and
now you can buy monster size enterprise class drives instead. I now
have two 18 Tbyte WD enterprise drives and a 20 Tbyte Seagate one, and
sundry smaller enterprise class drives (10-16 Tbytes). The Seagate
EXOS line usually are cheaper than the Red/NAS drives of the same size
from both Seagate and WD and perform better. They are not cheap, but
the performance is great, they have 5 year warranties and are huge.
And not shingled. It is fascinating watching a file copy between
these drives - they really do do 250 Mbytes/s, so about half what a
good SATA SSD will do. There are now 22 Tbyte enterprise drives
available and 24 Tbyte coming later this year.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Hoi Jan,

Saturday, March 11, 2023, 7:37:02 AM, you wrote:

> On 11/03/2023 05:53, Ram Ramesh wrote:
>> Do you mean mythtv will delete files even if they are not marked to be
>> deleted? I expect that it will not record any new shows when disk is
>> full. Deleting a recording that I want to keep is not very user
>> friendly.  I never had this happen as I always had enough space. May be
>> I never had to deal with it and therefore assumed this never happens.

> MythTV will only auto-delete recordings that have been set to
> auto-expire. So probably when discussing this functionality we should
> use that word: auto-expire.

> Each recording rule contains a flag that determines whether the
> recordings carried out under it will be marked to auto-expire. But you
> can also individually set or clear the auto-expire flags on already-made
> recordings.

> There's a brief write-up on the wiki here: [1].

> [1]: https://www.mythtv.org/wiki/Using_MythTV#How_MythTV_Records

> HTH, Jan

Not entirely true. Unless policies have changed in more recent mythtv
versions. It will first try to make space by deleting recordings set
for deletion and then those set to auto-expire. However finally it
will start with other recordings, oldest first. You can set several
parameters in your setup.

About deleting in-use files under Linux. This is entirely possible
without disturbing the in-use processes. When a directory entry is
deleted the actual data is still there and is in the background
protected from overwriting until it is no longer in-use.
This as opposed to Windows filesystems. This is why Windows needs
endlessly reboots during installation.

This goes for ext2/3/4 filesystems. I am not sure if this also goes
for the newer filesystems but I guess it does.


Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Hoi Ram,

Saturday, March 11, 2023, 5:23:47 PM, you wrote:

> Hoi Jan,

> Saturday, March 11, 2023, 7:37:02 AM, you wrote:

>> On 11/03/2023 05:53, Ram Ramesh wrote:
>>> Do you mean mythtv will delete files even if they are not marked to be
>>> deleted? I expect that it will not record any new shows when disk is
>>> full. Deleting a recording that I want to keep is not very user
>>> friendly.  I never had this happen as I always had enough space. May be
>>> I never had to deal with it and therefore assumed this never happens.

>> MythTV will only auto-delete recordings that have been set to
>> auto-expire. So probably when discussing this functionality we should
>> use that word: auto-expire.

>> Each recording rule contains a flag that determines whether the
>> recordings carried out under it will be marked to auto-expire. But you
>> can also individually set or clear the auto-expire flags on already-made
>> recordings.

>> There's a brief write-up on the wiki here: [1].

>> [1]: https://www.mythtv.org/wiki/Using_MythTV#How_MythTV_Records

>> HTH, Jan

> Not entirely true. Unless policies have changed in more recent mythtv
> versions. It will first try to make space by deleting recordings set
> for deletion and then those set to auto-expire. However finally it
> will start with other recordings, oldest first. You can set several
> parameters in your setup.

> About deleting in-use files under Linux. This is entirely possible
> without disturbing the in-use processes. When a directory entry is
> deleted the actual data is still there and is in the background
> protected from overwriting until it is no longer in-use.
> This as opposed to Windows filesystems. This is why Windows needs
> endlessly reboots during installation.

> This goes for ext2/3/4 filesystems. I am not sure if this also goes
> for the newer filesystems but I guess it does.


This comes from a different philosophy. Under Windows the directory
entry is the file and filelocks are set to the directory entry.
Under Linux a directory is just another file and filelocks are set to
the actual file or actually to the inodes. This is also why hardlinks
are possible under Linux and not under Windows.


Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 11/03/2023 16:23, Hika van den Hoven wrote:
> Hoi Jan,
>
> Saturday, March 11, 2023, 7:37:02 AM, you wrote:
>
>> On 11/03/2023 05:53, Ram Ramesh wrote:
>>> Do you mean mythtv will delete files even if they are not marked to be
>>> deleted? I expect that it will not record any new shows when disk is
>>> full. Deleting a recording that I want to keep is not very user
>>> friendly.  I never had this happen as I always had enough space. May be
>>> I never had to deal with it and therefore assumed this never happens.
>
>> MythTV will only auto-delete recordings that have been set to
>> auto-expire. So probably when discussing this functionality we should
>> use that word: auto-expire.
>
>> Each recording rule contains a flag that determines whether the
>> recordings carried out under it will be marked to auto-expire. But you
>> can also individually set or clear the auto-expire flags on already-made
>> recordings.
>
>> There's a brief write-up on the wiki here: [1].
>
>> [1]: https://www.mythtv.org/wiki/Using_MythTV#How_MythTV_Records
>
>> HTH, Jan
>
> Not entirely true. Unless policies have changed in more recent mythtv
> versions. It will first try to make space by deleting recordings set
> for deletion and then those set to auto-expire. However finally it
> will start with other recordings, oldest first. You can set several
> parameters in your setup.
>
> About deleting in-use files under Linux. This is entirely possible
> without disturbing the in-use processes. When a directory entry is
> deleted the actual data is still there and is in the background
> protected from overwriting until it is no longer in-use.
> This as opposed to Windows filesystems. This is why Windows needs
> endlessly reboots during installation.
>
> This goes for ext2/3/4 filesystems. I am not sure if this also goes
> for the newer filesystems but I guess it does.
>
The problem there is that, although the system considers the file deleted, the /space/ is not
released until the last user closes the (deleted) file. This is mythtv's problem, that it will
actually want to make use of that space.

--

Mike Perkins


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Hoi Mike,

Saturday, March 11, 2023, 6:18:31 PM, you wrote:

> On 11/03/2023 16:23, Hika van den Hoven wrote:
>> Hoi Jan,
>>
>> Saturday, March 11, 2023, 7:37:02 AM, you wrote:
>>
>>> On 11/03/2023 05:53, Ram Ramesh wrote:
>>>> Do you mean mythtv will delete files even if they are not marked to be
>>>> deleted? I expect that it will not record any new shows when disk is
>>>> full. Deleting a recording that I want to keep is not very user
>>>> friendly.  I never had this happen as I always had enough space. May be
>>>> I never had to deal with it and therefore assumed this never happens.
>>
>>> MythTV will only auto-delete recordings that have been set to
>>> auto-expire. So probably when discussing this functionality we should
>>> use that word: auto-expire.
>>
>>> Each recording rule contains a flag that determines whether the
>>> recordings carried out under it will be marked to auto-expire. But you
>>> can also individually set or clear the auto-expire flags on already-made
>>> recordings.
>>
>>> There's a brief write-up on the wiki here: [1].
>>
>>> [1]: https://www.mythtv.org/wiki/Using_MythTV#How_MythTV_Records
>>
>>> HTH, Jan
>>
>> Not entirely true. Unless policies have changed in more recent mythtv
>> versions. It will first try to make space by deleting recordings set
>> for deletion and then those set to auto-expire. However finally it
>> will start with other recordings, oldest first. You can set several
>> parameters in your setup.
>>
>> About deleting in-use files under Linux. This is entirely possible
>> without disturbing the in-use processes. When a directory entry is
>> deleted the actual data is still there and is in the background
>> protected from overwriting until it is no longer in-use.
>> This as opposed to Windows filesystems. This is why Windows needs
>> endlessly reboots during installation.
>>
>> This goes for ext2/3/4 filesystems. I am not sure if this also goes
>> for the newer filesystems but I guess it does.
>>
> The problem there is that, although the system considers the file deleted, the /space/ is not
> released until the last user closes the (deleted) file. This is mythtv's problem, that it will
> actually want to make use of that space.


True, I just responded to the question: "What happens if I delete a
recording that is currently being watched?"

If Mythtv deletes a file and does not get the expected free space, I
guess it will keep on deleting recordings until the set minimal
free space is reached.


Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Mike Perkins <mikep@randomtraveller.org.uk> wrote:

>> About deleting in-use files under Linux. This is entirely possible
>> without disturbing the in-use processes. When a directory entry is
>> deleted the actual data is still there and is in the background
>> protected from overwriting until it is no longer in-use.
>> This as opposed to Windows filesystems. This is why Windows needs
>> endlessly reboots during installation.

Interestingly I was taken to task on this not long ago when I pointed this out. Apparently “modern” (i.e. not the ancient [something]FAT ones) do support unlinking of files. But then the entire MS ecosystem is, from observation, such a cobbled together hodge-lodge of new lipstick over old stuff that I suspect the facility is not used simply because it would mean re-writing so much stuff - and it’s easier to just make the user do the work.

>> This goes for ext2/3/4 filesystems. I am not sure if this also goes
>> for the newer filesystems but I guess it does.

It should hold for any Unix[like] system as it’s used by so many things that would break if the filesystem didn’t support it.

> The problem there is that, although the system considers the file deleted, the /space/ is not released until the last user closes the (deleted) file. This is mythtv's problem, that it will actually want to make use of that space.

That does depend on how much space you have set Myth to keep free, and how big your recordings are. With my settings, I’d have probably finished watching a recording (and therefore, the file would have been closed and deleted) long before the disk filled up. But then I don’t tend to rely on Myth for cleaning up - I either have a bit of a manual purge, or add some disks space whenever space starts getting low.

Simon
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 11/03/2023 18:32, Hika van den Hoven wrote:
> True, I just responded to the question: "What happens if I delete a
> recording that is currently being watched?"
>
> If Mythtv deletes a file and does not get the expected free space, I
> guess it will keep on deleting recordings until the set minimal
> free space is reached.

Hika's points are valid only if the backend hasn't been configured to
delete slowly.

Slow deletion involves progressively truncating the file, so this would
have an impact on other users (unless they have locked the file in which
case the truncation would fail).
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 3/11/23 11:32, Hika van den Hoven wrote:
>
>>>> HTH, Jan
>>> Not entirely true. Unless policies have changed in more recent mythtv
>>> versions. It will first try to make space by deleting recordings set
>>> for deletion and then those set to auto-expire. However finally it
>>> will start with other recordings, oldest first. You can set several
>>> parameters in your setup.
Can I set parameters such that it skips recording new show to save a
recording that is not marked to be deleted or auto-expire? I mean
recorded shows are more important that new recordings for me as I have a
habit or deleting anything that I watch and do not think I will watch
again. Thus if I keep a recording, I keep it intentionally/deliberately
and I do not want mythtv getting smart or second guessing my choice.

Regards
Ramesh

On 11/03/2023 18:34, Ram Ramesh wrote:
> On 3/11/23 11:32, Hika van den Hoven wrote:
>>
>>>>> HTH, Jan
>>>> Not entirely true. Unless policies have changed in more recent mythtv
>>>> versions. It will first try to make space by deleting recordings set
>>>> for deletion and then those set to auto-expire. However finally it
>>>> will start with other recordings, oldest first. You can set several
>>>> parameters in your setup.
> Can I set parameters such that it skips recording new show to save a recording that is not marked to
> be deleted or auto-expire? I mean recorded shows are more important that new recordings for me as I
> have a habit or deleting anything that I watch and do not think I will watch again. Thus if I keep a
> recording, I keep it intentionally/deliberately and I do not want mythtv getting smart or second
> guessing my choice.
>
The best way to keep anything you really don't want to delete is to move it to your video directory
using one of the many available scripts (depending on format, mostly). That way mythtv will never
touch them.

--

Mike Perkins


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Hoi Ram,

Saturday, March 11, 2023, 7:34:07 PM, you wrote:

> On 3/11/23 11:32, Hika van den Hoven wrote:


>
>
>
>
> HTH, Jan

>
>

> Not entirely true. Unless policies have changed in more recent mythtv
> versions. It will first try to make space by deleting recordings set
> for deletion and then those set to auto-expire. However finally it
> will start with other recordings, oldest first. You can set several
> parameters in your setup.
>
>
>
> Can I set parameters such that it skips recording new show to
> save a recording that is not marked to be deleted or
> auto-expire? I mean recorded shows are more important that new
> recordings for me as I have a habit or deleting anything that I
> watch and do not think I will watch again. Thus if I keep a
> recording, I keep it intentionally/deliberately and I do not
> want mythtv getting smart or second guessing my choice.
>
> Regards
> Ramesh
>
As far as I know, you can not set a recording to never delete. In your
frontend: Information Center => System Status => AutoExpire List
you can see which in what order will be deleted first.

It however will normally first delete older recordings.

Within a recordingrule you can limit the number off recordings and
choose wether to delete the oldest or abort recording when that limit
is reached.

However I have hardlinked recordings, I intend to keep, to a
meaningful name in my videos directory. I know this could be confusing
to mythtv, but this way if mythtv would delete the recording it will
still be there.
I could just move them to the videos directory, but I find the display
interface for recordings beter and there I have more freedom on
naming, description etc.


Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Saturday 11 March 2023 04:45:33 PM (-06:00), Hika van den Hoven wrote:
...
> As far as I know, you can not set a recording to never delete. In your
> frontend: Information Center => System Status => AutoExpire List
> you can see which in what order will be deleted first.

Storage Options -> Preserve This Episode

I do have this set on 4 very old recordings, but also did the Disable Auto
Expire
on them.

--
Bill
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Hoi Bill,

Sunday, March 12, 2023, 12:09:58 AM, you wrote:


> On Saturday 11 March 2023 04:45:33 PM (-06:00), Hika van den Hoven wrote:
> ...
>> As far as I know, you can not set a recording to never delete. In your
>> frontend: Information Center => System Status => AutoExpire List
>> you can see which in what order will be deleted first.

Storage Options ->> Preserve This Episode

> I do have this set on 4 very old recordings, but also did the Disable Auto
> Expire
> on them.

I never noticed that one. But since years ago the deleting proces once
went amok, I do not 100% trust Mythtv on that respect. I then started
with the hardlinking. I however should set that flag on all hardlinked
recordings. It at least should put them to the end of the deletion
queue, preventing confusion for Mythtv.


Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org