[WebIF] Feature Requests

/df said:
If you are happy to get into the shell command line, through Webshell, telnet or SSH, you can find the ffmpeg process and kill it (pkill ffmpeg). That will cause the job to fail.
Click to expand...
We really need an easier way of getting rid of long running queued tasks,

Storing the PID of the currently running queued task in the queue.db entry would be one option but it is fairly complicated to add a new field to an existing database definition but then I realised that is not actually needed.
By design only one queued task can be running at a time so rather than a pid field in each queue entry it only needs a single pid to be stored which could be in the settings database or in a simple file.

So,
  1. When starting a queued task save the pid of the started task in file/db
  2. (optionally) When task ends delete saved pid
  3. Add 'Kill current task' button to queue display button, button action issues kill pid command
  4. (optionally) Disable kill button when no task active, Display pid on Queue panel
 
Hi
Firstly I'd like to say how I really appreciate all the hard work that has gone into, and continues to go into this system. I use it daily and continue to explore different facets as time goes on.
As I use the WebIF for scheduling, I wonder why the EPG screen doesn't make full use of the page width, as the per-channel page does. As I like to look at a 6-hours grid, this would be of real benefit.
Thanks
Andy
 
ANDYWE said:
Hi
Firstly I'd like to say how I really appreciate all the hard work that has gone into, and continues to go into this system. I use it daily and continue to explore different facets as time goes on.
As I use the WebIF for scheduling, I wonder why the EPG screen doesn't make full use of the page width, as the per-channel page does. As I like to look at a 6-hours grid, this would be of real benefit.
Thanks
Andy
Click to expand...
I presume you mean the grid-style EPG page? It uses 95% of my screen width, what is it doing on yours (a screen shot would be best)?
 
No problem - see attached
This is using Firefox, Win10 @ 1920x1080
The same on Edge.
 

Attachments

  • Humax T2 Custom Firmware - EPG and Version.jpg
    Humax T2 Custom Firmware - EPG and Version.jpg
    295 KB · Views: 12
Those screen shots (which I presume you've pasted into a spreadsheet to assemble into one instead of just attaching them separately :rolleyes:) look a lot wider than 16:9, but yes I can see what you mean. My "95%" is on a 4:3 screen, and it looks like the EPG grid has a fixed rather than responsive width... but it might have been too much of a pain in the arse to design with responsiveness.

How do you find the EPG on the Remote Scheduling website?
 
ANDYWE said:
No problem - see attached
This is using Firefox, Win10 @ 1920x1080
The same on Edge.
Click to expand...
peterworks said:
With the same setup (Windows 10 and Firefox) I get roughly the same as the OP:
Click to expand...
If you go unto Windows 10's Settings -> Display -> Scale and layout, what is "Change the size of text, apps and other items" set to? Is it different to the recommended option (which will include "(Recommended)" in its text.

MymsMan's Windows 11 1920x1080 looks as though it is set to 150%, which would account for the difference between yours and MymsMan's.
 
Last edited:
Black Hole said:
Those screen shots (which I presume you've pasted into a spreadsheet to assemble into one instead of just attaching them separately :rolleyes:) look a lot wider than 16:9, but yes I can see what you mean. My "95%" is on a 4:3 screen, and it looks like the EPG grid has a fixed rather than responsive width... but it might have been too much of a pain in the arse to design with responsiveness.

How do you find the EPG on the Remote Scheduling website?
Click to expand...
Maybe the excel based collation was a bit un-necessary :whistling: - it is definitely 1920 x 1080, at !00% scaling.
As @prpr indicated, the grid appears to be fixed width, not scaling or adapting to resizing the browser window (looks super on a landscape ipad by the way)

The RS website EPG renders in the same dimensions as the T2 WebIF EPG.

Just a thought - can the EPG grid pixel value be fiddled with using built-in browser dev tools?
 
ANDYWE said:
Just a thought - can the EPG grid pixel value be fiddled with using built-in browser dev tools?
Click to expand...
No, it's all hard-coded server side i.e. on your Humax. You can edit it there if you like (/mod/webif/html/xepg/index.jim), but it'll get overwritten the next time the WebIf gets upgraded.
TBH, the whole page needs throwing away and starting again.
 
Thanks @prpr I have done that and am very happy with the improvement.
Steps taken shown below
  1. Back up the index.jim file (cp index.jim index.jim.bak)
  2. Edit the index.jim file using nano ( nano index.jim)
  3. Change the line "set eventpx=1000" to "set eventpx=1600"
  4. Save the file (^O)
  5. Reload the EPG webpage
If the PC browser window is smaller than the table then a horizontal scroll bar is put in place.
Note that on the ipad I see the full page width rendered making the page zoomed out / smaller text. I am okay with that as I use the PC and am the only WebIF user in the house.

1714829820613.png
 
Could eventpx be implemented as a setting? Perhaps "preferred screen width" (in pixels) could be a setting and then eventpx (and any other width-sensitive elements) refer to it.

I realise there are responsive methods for adapting to screen width, but I think those are actioned in the browser rather than the server having knowledge of the screen width, so putting it in a setting the server has access to might be a lot easier than trying to be responsive.
 
MymsMan said:
We really need an easier way of getting rid of long running queued tasks
Click to expand...
This is now implemented in 1.5.2-13 in the Beta area.
Any other packages with plugins (qtube) need modifying to use system qexec rather than exec in queue.hook
 
prpr said:
This is now implemented in 1.5.2-13 in the Beta area.
Any other packages with plugins (qtube) need modifying to use system qexec rather than exec in queue.hook
Click to expand...
Thanks, but ...
  • Tried it with a decrypt job and it did cancel the task, but a few seconds later it was Running again
    :(
    There is a short window in which you can move the entry into Hold but easy to miss making it look as if it hasn't been killed
    It would probably be better if killing the task automatically moved it into Hold or a new Killed status, it could then be manually resubmitted when user wants to try again.
  • I had assumed (mistake) that the monitoring would occur is deq before/after invoking the hook routines to avoid the need for changes in the queue.hook routines themselves
  • I can make the changes in detectads and qtube but I have never added packages to the beta repository before - how do I?
  • If I don't use beta I won't be able to release the updates before the changes make it to the main repository (which I can update)
 
You must log in or register to reply here.
Back
Top