Plainly it's not ideal, verging on POSSLQ-exclusive. In due course I could add that sequence to the remote start-up sequence or perhaps organise some CF trickery to send the commands. Or identify which component has gone off-spec and replace it. Could the matching item be in a sacrificial Humax...
My experience after a few weeks with an HDMI-capable AV receiver between the aged Humax, with Pin 19 isolated, and the TV is that the sound is available at turn-on but the TV display is black. Supposing that the set-up had been running at 1080p before turning off, a series of 6 V.Format remote...
Didn't we find some guidance in the spec regarding what period might be "significant" in relation to the what the Humax s/w subtracts from the next scheduled event to calculate its wake-up time?
The TDA9984A HDMI o/p chip isn't meant to support 1920x540, so I suppose something must have made its 1080i seem like 540p.
At least the tuner from which the EPG and TV out is derived developed twisted underwear and then worked again after power cycling. Is that surprising?
I guess component failure when what formerly worked failed first intermittently and then permanently. But digital security is all about introducing new failure modes that manifest themselves as "computer says no": that would especially have applied when a whole lot of HDMI implementations were...
My guess is that because of failing to complete the negotiation the Humax s/w (?) fails to enforce HDCP (which is initially off): https://hummy.tv/forum/threads/green-screen-known-as-hdmi-handshake-for-me-finally-cured.11456/post-176627.
Adding to the above, I suppose a passive switch would...
There's a logical problem with the status display where I added the (delayed) case with too little thought.
When the programme being watched is from the timeshift buffer:
the programme name is only correct if the delay is shorter than the length of the show so far broadcast;
the % value shows...
tldr; what BH said.
We don't really have a way to add useful functionality like this, requiring user input, to the on-screen application. The Trash bin appears since it's part of the filesystem but doesn't get different menus, etc, even if the underlying behaviour is modified by CF hook code...
Maybe I'm intuiting incorrectly, but it seemed to me that @Sargan might be wanting to search programme metadata rather than just the filenames. It doesn't seem an unreasonable function to offer in the Browse Files page.
Or create a sweeper rule to find the file. I suppose the UI will be a bit rubbish: set the rule to stop when a match is found; review sweeper log after running it with Run Now to find which file, if any, was found.
Just starting Python and loading the yt-dl code (it's already extracted now, IIRC) takes a minute or 2. The majority of the remaining execution time, I'm sure, is spent executing the n-sig challenge JS. If we had a native ES6 JavaScript interpreter on the platform it might be a lot quicker, but...
Plainly it's not ideal, verging on POSSLQ-exclusive. In due course I could add that sequence to the remote start-up sequence or perhaps organise some CF trickery to send the commands. Or identify which component has gone off-spec and replace it. Could the matching item be in a sacrificial Humax...
My experience after a few weeks with an HDMI-capable AV receiver between the aged Humax, with Pin 19 isolated, and the TV is that the sound is available at turn-on but the TV display is black. Supposing that the set-up had been running at 1080p before turning off, a series of 6 V.Format remote...
Didn't we find some guidance in the spec regarding what period might be "significant" in relation to the what the Humax s/w subtracts from the next scheduled event to calculate its wake-up time?
The TDA9984A HDMI o/p chip isn't meant to support 1920x540, so I suppose something must have made its 1080i seem like 540p.
At least the tuner from which the EPG and TV out is derived developed twisted underwear and then worked again after power cycling. Is that surprising?
I guess component failure when what formerly worked failed first intermittently and then permanently. But digital security is all about introducing new failure modes that manifest themselves as "computer says no": that would especially have applied when a whole lot of HDMI implementations were...
My guess is that because of failing to complete the negotiation the Humax s/w (?) fails to enforce HDCP (which is initially off): https://hummy.tv/forum/threads/green-screen-known-as-hdmi-handshake-for-me-finally-cured.11456/post-176627.
Adding to the above, I suppose a passive switch would...
There's a logical problem with the status display where I added the (delayed) case with too little thought.
When the programme being watched is from the timeshift buffer:
the programme name is only correct if the delay is shorter than the length of the show so far broadcast;
the % value shows...
tldr; what BH said.
We don't really have a way to add useful functionality like this, requiring user input, to the on-screen application. The Trash bin appears since it's part of the filesystem but doesn't get different menus, etc, even if the underlying behaviour is modified by CF hook code...
Maybe I'm intuiting incorrectly, but it seemed to me that @Sargan might be wanting to search programme metadata rather than just the filenames. It doesn't seem an unreasonable function to offer in the Browse Files page.
Or create a sweeper rule to find the file. I suppose the UI will be a bit rubbish: set the rule to stop when a match is found; review sweeper log after running it with Run Now to find which file, if any, was found.
Just starting Python and loading the yt-dl code (it's already extracted now, IIRC) takes a minute or 2. The majority of the remaining execution time, I'm sure, is spent executing the n-sig challenge JS. If we had a native ES6 JavaScript interpreter on the platform it might be a lot quicker, but...
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.