-
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.
[webif] Web Interface 1.2.x
- Thread starter af123
- Start date
prpr
Well-Known Member
Back in the summer (in BST), when I was playing with tunefix on my spare box, I needed a way to stop the auto schedule restore from running every time, so I set up a manual recording for something random a long-ish way in the future - this happened to be for 23:55-00:15 overnight tonight.
Now that I've looked at it today (in GMT), the on-screen UI correctly says 23:55-00:15 but the WebIf says 22:55-23:15.
Investigating the database directly, I see nsttime is set to 1451602500 which corresponds to 22:55, but szsttime is set to "20151231235500".
I've probably done a restore schedule of one sort or another since originally setting it up, so not sure where the inconsistency has crept in.
I wonder which one will get recorded? My guess is the latter but tomorrow will tell.
Now that I've looked at it today (in GMT), the on-screen UI correctly says 23:55-00:15 but the WebIf says 22:55-23:15.
Investigating the database directly, I see nsttime is set to 1451602500 which corresponds to 22:55, but szsttime is set to "20151231235500".
I've probably done a restore schedule of one sort or another since originally setting it up, so not sure where the inconsistency has crept in.
I wonder which one will get recorded? My guess is the latter but tomorrow will tell.
Black Hole
May contain traces of nut
Pertaining to the discussion about the Foxsat WebIF in this topic: http://hummy.tv/forum/threads/scheduled-events-feature-request.6805/
The way the HDR-FOX CF implements the option to rename the destination folder for a scheduled series recording seems more logical to me, in that (as far as I know) it simply tweaks the data in the schedule database so that the Humax creates/uses a different folder at record time, with the option to pre-create the folder in case one needs to mark it for no-flatten etc.
If the user did happen to want to move any existing recordings in the previous target folder (if any) into the new target folder, it is an easy enough operation to mark them all for move through the WebIF media browser, but we could have the best of both worlds if the rename target folder dialogue popped up an option box (if the previous target folder happens to exist already) "Transfer existing recordings in this series to the new folder? Y/N".
The way the HDR-FOX CF implements the option to rename the destination folder for a scheduled series recording seems more logical to me, in that (as far as I know) it simply tweaks the data in the schedule database so that the Humax creates/uses a different folder at record time, with the option to pre-create the folder in case one needs to mark it for no-flatten etc.
If the user did happen to want to move any existing recordings in the previous target folder (if any) into the new target folder, it is an easy enough operation to mark them all for move through the WebIF media browser, but we could have the best of both worlds if the rename target folder dialogue popped up an option box (if the previous target folder happens to exist already) "Transfer existing recordings in this series to the new folder? Y/N".
prpr
Well-Known Member
The latter did get recorded, so the WebIf display is wrong.
I've got a feeling I've posted about this before as well now that I think about it, but ICBA to search for it ATM.
Are you aware that the number on each folder tells you the number of UNWATCHED programs in the folder not the number total number of programs (unless they are all unwatched of course). Running reset new will reset them all to unwatched, which may not be what you actually require.
Sent from my iPad using Tapatalk
Sent from my iPad using Tapatalk
Yes I am aware of that and the folder in question has UNWATCHED items.
hairy_mutley
Active Member
Is there no diagnostic that will reset the unwatched count (when it is incorrect) other than resetnew or are they inextricably linked?
prpr
Well-Known Member
Yes, that's fixed it. I don't know whether this gives a clue to anything:
It would be nice to have a "restart" option on service.
Code:
humax ~ # service stop lighttpd
Stopping lighttpd...
sh: you need to specify whom to kill
Done.
humax ~ # service start lighttpd
Starting lighttpd...
Done.
humax ~ # service stop lighttpd
Stopping lighttpd...
Done.prpr
Well-Known Member
Trivial and seems to work:
Code:
--- /mod/bin/service~
+++ /mod/bin/service
@@ -62,6 +62,7 @@
case "$1" in
start) shift; control start "$@" ;;
stop) shift; control stop "$@" ;;
+ restart) shift; control stop "$@" ; control start "$@" ;;
toggle) shift; control toggle "$@" ;;
auto) shift; auto "$@" ;;
mlist)
@@ -91,6 +92,7 @@
Syntax:
service start <service>
service stop <service>
+ service restart <service>
service auto <service> (toggles autostart)
EOMIt was on but I turned it off and on again and the numbers are back.
Strange but sorted.
Thank you.
peterworks
Ye Olde Bowler
Have had this problem for quite a while. In another thread it was suggested putting:
10,40 * * * * diag resetnew >/dev/null 2>&1 in /mod/var/spool/cron/crontabs/root
(This runs resetnew at 10 and 40 minutes past the hour)
Since doing this my count has been accurate.
At the very least it is a good workaround...
Thread: http://hummy.tv/forum/threads/webif-web-interface-1-2-4.6484/page-7#post-90633
10,40 * * * * diag resetnew >/dev/null 2>&1 in /mod/var/spool/cron/crontabs/root
(This runs resetnew at 10 and 40 minutes past the hour)
Since doing this my count has been accurate.
At the very least it is a good workaround...
Thread: http://hummy.tv/forum/threads/webif-web-interface-1-2-4.6484/page-7#post-90633
Last edited:
Done but still the same.
I did try that as you can see in the thread but it never worked on the one folder I had issues with.
Funnily enough one of the folders I am having the issue with now is on the same channel and part of the same TV series.