• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

[auto-schedule-restore] Auto-restore schedule after retune

Owen Smith said:
Why does tunefix-update need that?
Click to expand...
It doesn't need it. It's just the easiest way of achieving it.
I had assumed it connected to some sort of data feed a bit like the remote schedule server.
Click to expand...
I suggest you read post #1 of the tunefix-update thread.
If tunefix-update requires auto-update then it's a non starter on my parents' box.
Click to expand...
It doesn't. You could set up a Cron job yourself just to do "opkg update; opkg install tunefix-update" on a daily (or whatever) basis.
 
prpr said:
It doesn't need it. It's just the easiest way of achieving it.

I suggest you read post #1 of the tunefix-update thread.

It doesn't. You could set up a Cron job yourself just to do "opkg update; opkg install tunefix-update" on a daily (or whatever) basis.
Click to expand...

The fundamental point is tunefix-update does its work by the package itself being updated. It's one shot software, by the time it's been installed it has no actual work to do until it is replaced by a newer version. As a programmer myself that's not how I'd have gone about it, by it's nature it cuts out some user scenarios. I assumed it was checking in with a server periodically to see what changes to channels had been made, which is something I could have accepted at my parents.

I'm not even sure I'm happy using tunefix-update at my house given the way it works. I tend to keep my box running the identical set of packages to those running at my parents' and my aunt's so if the packages themselves give trouble I will see the same problems and can advise. It's a method that has served me well on a couple of occasions and I'm keen to stick to it. Remote tech support by phone is easier when I'm running the same software.

So I guess that leaves me with either running auto-schedule-restore and accepting the randomness with which the broadcasters flag a DSO (it'll sort my aunt's box out occasionally, which is enough for her), or continuing with disable-dso and doing the tuning manually (which given my parents are in a transmitter overlap area is probably what I'll do for them). Fortunately my parents have an "it's only telly" attitude and if they miss something they're not bothered. My aunt doesn't mind losing recordings but gets annoyed when weird channels like 5* go missing that she's been watching NCIS re-runs on or whatever, so an occasional DSO should do for her.

I'm sure your tunefix-update package works great for the people who's use cases it fits. Generally slightly technical people who have auto update of all packages enabled and can sort things out when they go wrong. It's my problem that this doesn't fit some of my family's use cases. At least I have a clear grasp of the situation now.
 
Owen Smith said:
The fundamental point is tunefix-update does its work by the package itself being updated. It's one shot software, by the time it's been installed it has no actual work to do until it is replaced by a newer version. As a programmer myself that's not how I'd have gone about it, by it's nature it cuts out some user scenarios.
Click to expand...
Is this not sort of similar to an anti virus program's database. It's the AV program that checks for the updates, not the virus database, but it;s the virus database that gets updated. Well, that's how the reference post reads to me, insofar as it's just a database update as opposed tho a program update. I wonder how you would have gone about it differently so that perhaps prpr can 'improve' the way it works to fit in to a wider user bases use bases?
 
Trev said:
Is this not sort of similar to an anti virus program's database. It's the AV program that checks for the updates, not the virus database, but it;s the virus database that gets updated. Well, that's how the reference post reads to me, insofar as it's just a database update as opposed tho a program update. I wonder how you would have gone about it differently so that perhaps prpr can 'improve' the way it works to fit in to a wider user bases use bases?
Click to expand...

Packages involve code unless I misunderstand unix more than I'm aware. So it might be mostly a database but it has to come in a wrapper of code.

I'd have built it to work like the remote scheduler where it checks in with a server periodically to see what updates to make. Indeed it seems like an obvious extra feature for rs to me, as well as getting recordings that the user has set remotely it could get channel tuning updates if the user had turned that on as an option.
 
It may well be a possible a extension to RS, but the fact is prpr has developed and provided us with tunefix, without access to the server-side development that it would take.

It seems to me entirely irrelevant whether the information is accessed as a database or as a database encoded in software - the software itself would only be "dangerous" if it had a malicious payload and was not confined to implementing the intended effect. You are concerned about untested software, but the software framework is tested - it's just the data that changes.
 
Owen Smith said:
The fundamental point is tunefix-update does its work by the package itself being updated. It's one shot software, by the time it's been installed it has no actual work to do until it is replaced by a newer version. As a programmer myself that's not how I'd have gone about it, by it's nature it cuts out some user scenarios. I assumed it was checking in with a server periodically to see what changes to channels had been made, which is something I could have accepted at my parents.
Click to expand...
It works the way it does because it's incredibly simple to do, given the underlying tunefix architecture. Doing what you suggest is orders of magnitude more complicated and I don't have a server.
It's deliberately one shot so that if somebody doesn't like what's happened, then it won't happen again.
It also doesn't consume system resources constantly that some sort of daemon would.
I'm sure your tunefix-update package works great for the people who's use cases it fits.
Click to expand...
(whose)
It works for me, and that's who I wrote it for. Nobody else. If you don't want to use it, that's fine. If you do, that's fine too. I don't care!

Anyway, this thread has drifted somewhat from its intended topic, so best to carry on discussion elsewhere if there is anything else to say, although I'm not sure there is.
 
I have had a completely different idea. Have a package that watches for the broadcast EPG on the box containing changed channels (extra ones, deleted ones, moved mux ones) and if it spots such sticks a DSO event into the schedule. After that the job is done by auto-schedule-restore.

I meant no insult to your work prpr. It just doesn't fulfill my requirements, given my relatives I'm supporting.
 
Owen Smith said:
Have a package that watches for the broadcast EPG on the box containing changed channels
Click to expand...
Not possible (on the T2 itself). You'd need access the the relevant PID stream (the NIT if memory serves) and it's already stripped out before you can get to it.
 
prpr said:
Not possible (on the T2 itself). You'd need access the the relevant PID stream (the NIT if memory serves) and it's already stripped out before you can get to it.
Click to expand...

We can see the list of channels though. If that's different to what it was list time (on last boot probably), add a DSO event. It wouldn't catch a pure change of mux for a channel but would catch most other stuff.
 
prpr said:
I don't know what you're talking about. I'm not sure you do either.
Click to expand...

In one of the databases there is a list of channels. The custom firmware can see it, otherwise it would be impossible for the web epg to display channel names.

But it's clear from your attitude that you think I'm an idiot, so I'll spend my time doing something useful rather than discussing something that no-one is showing any interest in.
 
The database has the list of channels (services) that are tuned in on your box. This is NOT NECESSARILY the list of channels (services) that is being broadcast (which is in the NIT as I said before and to which we don't have access as it's already been stripped from the transport stream).
Additions to the latter list are not reflected in the former unless you do a retune (or get them in by other means e.g. tunefix-update). So you cannot use the former to trigger anything.
No-one is showing any interest because what you suggested is not possible (on the Humax).
 
Is it possible to convert an auto backup to behave like a manual backup (ie not get auto-deleted)? I want to preserve the pre-retune backup because it can't be reinstated until I get all my services back.
 
Black Hole said:
Is it possible to convert an auto backup to behave like a manual backup (ie not get auto-deleted)? I want to preserve the pre-retune backup because it can't be reinstated until I get all my services back.
Click to expand...

Simple in your webshell or telnet shell session ...
Code: 
cp /mod/var/backup/auto-yyyy-Mmm-dd-mm:ss.rbk /mod/var/backup/backup-yyyy-Mmm-dd-mm:ss.rbk
Or, more sophisticated:
Code: 
save_auto_backup() { # timestamp
    local mvb="/mod/var/backup"
    cp "$mvb/auto-$1.rbk" "$mvb/backup-$1.rbk"
}

save_auto_backup "yyyy-Mmm-dd-mm:ss"  || echo "Failed"
 
I thought I had found an even easier way - file name editing via an FTP-capable file explorer... but it threw out the colon!

In any case, thanks for the path and the confirmation that it only needs the filename changing.
 
I have auto-schedule-restore installed and it has never worked after a re-tune. Please advise what I might be doing wrong! I am just about to reprogramme all of my recordings - deep joy

Thanks
 
You must log in or register to reply here.
Back
Top