I saw this last night (I was away and had limited access) and I was going to suggest modifying seriesfiler as all the key features are already in there. But now I get back and I find that af123 has beaten me to it!
You can specify either the full path, or the name of the folder under "My Video". If you don't specify a path then it will process everything in and under "My Video".
IPSec, SSL and TLS support null encryption and they are all "real encryption systems". I suspect that it's all academic though, because those are network encryption schemes that are designed to interwork between computers, so negotiation is feasible. In the case of the Humax, encryption either...
Possibly you're thinking of 'null encryption' which is a test mode for cryptosystems that allows you to test everything except for the actual encryption.
Yep, there's a logical partition in there with the extra ones inside it. It has a few different tools and OSs that I use when rescuing systems or when I need to spin up a copy of Linux.
I plugged it in for testing my progbackup script so I could test the "Which drive do you want to back up to?"...
I've got a USB stick plugged into my HDR that has 7 partitions - 1 vfat and 6 ext2, and they are all automatically mounted on media/drive1-7. This does sound like a driver problem to me.
It was great to solve the decryption issue through the crafty use of database manipulation, DLNA and wget, but I have a nagging worry that this is something that Humax might want to lock down at a later date. I'd still love to find out how to do the decryption the 'proper' way.
I'd be surprised if 3DES was in use because that would result in a lot of encryption processing. It's much more likely that AES is being used as that was designed to use less processing power.
You have probably moved on from here, but if you install the lsof package and run the lsof command, you will be able to see what process has which files open in the filesystem. That's what I use to find out if the humax process is still recording a file or not.
I have added a 'disable' option to unencryptsetup, as well as removing the line from cron when uninstalling.
Version 0.1.1 is now on its way to the repository.
The simplest way to do it is to uninstall the package which will remove the crontab entries. If you want to stop it manually, then you need to edit the crontab (/mod/var/spool/cron/crontabs/root) to remove all references to /mod/sbin/unencrypt and then restart the cron services...
Yes, but the logic would mean that one directory would need to complete decryption before the other one started. In a lot of circumstances that would be OK, but I'm sure that it could be a problem for others.
For the moment, the script will only process what is under the directory specified, or all recordings. I'd need to do some digging to work out how to send multiple directories to the script from the crontab.
It'll keep checking indefinitely, but that's to account for new recordings. The program itself runs once every 15 minutes and just exits if there are no new recordings, so it shouldn't be a big overhead.
There's a package on its way to the repository, called "unencrypt"
Once it is installed, run unencryptsetup and give it the name of the directory that you want to experiment with, e.g.
unencryptsetup "Bob's Videos"
This will then update the cron table and schedule the program to run every 15...
To package it up, I need to write a script that will update the crontab and restart the cron service, so that it can be safely tested on a smaller directory and not just set the script loose on ALL videos. I'm working on some different stuff at the moment but will get stuck in again later.
Try downloading and installing the lsof package. Lsof tells you ALL of the files that are open, but if you filter on the name of a process, it becomes easier to interpret, try
lsof | grep humaxtv
to begin with as that will show you all the files in use by the humax process itself, but it may be...
I saw this last night (I was away and had limited access) and I was going to suggest modifying seriesfiler as all the key features are already in there. But now I get back and I find that af123 has beaten me to it!
You can specify either the full path, or the name of the folder under "My Video". If you don't specify a path then it will process everything in and under "My Video".
IPSec, SSL and TLS support null encryption and they are all "real encryption systems". I suspect that it's all academic though, because those are network encryption schemes that are designed to interwork between computers, so negotiation is feasible. In the case of the Humax, encryption either...
Possibly you're thinking of 'null encryption' which is a test mode for cryptosystems that allows you to test everything except for the actual encryption.
Yep, there's a logical partition in there with the extra ones inside it. It has a few different tools and OSs that I use when rescuing systems or when I need to spin up a copy of Linux.
I plugged it in for testing my progbackup script so I could test the "Which drive do you want to back up to?"...
I've got a USB stick plugged into my HDR that has 7 partitions - 1 vfat and 6 ext2, and they are all automatically mounted on media/drive1-7. This does sound like a driver problem to me.
It was great to solve the decryption issue through the crafty use of database manipulation, DLNA and wget, but I have a nagging worry that this is something that Humax might want to lock down at a later date. I'd still love to find out how to do the decryption the 'proper' way.
I'd be surprised if 3DES was in use because that would result in a lot of encryption processing. It's much more likely that AES is being used as that was designed to use less processing power.
You have probably moved on from here, but if you install the lsof package and run the lsof command, you will be able to see what process has which files open in the filesystem. That's what I use to find out if the humax process is still recording a file or not.
I have added a 'disable' option to unencryptsetup, as well as removing the line from cron when uninstalling.
Version 0.1.1 is now on its way to the repository.
The simplest way to do it is to uninstall the package which will remove the crontab entries. If you want to stop it manually, then you need to edit the crontab (/mod/var/spool/cron/crontabs/root) to remove all references to /mod/sbin/unencrypt and then restart the cron services...
Yes, but the logic would mean that one directory would need to complete decryption before the other one started. In a lot of circumstances that would be OK, but I'm sure that it could be a problem for others.
For the moment, the script will only process what is under the directory specified, or all recordings. I'd need to do some digging to work out how to send multiple directories to the script from the crontab.
It'll keep checking indefinitely, but that's to account for new recordings. The program itself runs once every 15 minutes and just exits if there are no new recordings, so it shouldn't be a big overhead.
There's a package on its way to the repository, called "unencrypt"
Once it is installed, run unencryptsetup and give it the name of the directory that you want to experiment with, e.g.
unencryptsetup "Bob's Videos"
This will then update the cron table and schedule the program to run every 15...
To package it up, I need to write a script that will update the crontab and restart the cron service, so that it can be safely tested on a smaller directory and not just set the script loose on ALL videos. I'm working on some different stuff at the moment but will get stuck in again later.
Try downloading and installing the lsof package. Lsof tells you ALL of the files that are open, but if you filter on the name of a process, it becomes easier to interpret, try
lsof | grep humaxtv
to begin with as that will show you all the files in use by the humax process itself, but it may be...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.