user-2427
24-08-2019, 09:49 PM
Hopefully the best way to pass on this info/experience. Whether or not it's solvable, or even a thing.
Version 3.22 (and 3.21, when also tried) of the Win32 release fails to install with "[path-and-exe-name] is not a valid Win32 application". Confirmed with multiple download attempts from github via subtly different download methods to try to iron out the usual glitches. The .exe icon is the correct get_iplayer one, in all cases, so seems to be at least partially a valid binary executable and not accidentally stripped to 7bit or something like used to happen in olden times.
Discovered when attempting to update the prior 3.20 install that was suddenly giving the "0 programmes found" error*, that cropped up for Radio (most important for my purposes) and TV; and specifically noted as now solved, before I'd even encountered it and gone looking!
(* - In a separate personal scraping of future radio schedules for interesting programmes to try to listen to live, I had noted the restructured data - I used to search and isolate the data I needed by keying in on the "@CONTEXT" string in the raw html, with my own separate code, then suddenly found it was the second instance! So I imagine that's also related to what broke the get_iplayer cache-building, and has had to be fixed.)
This is on an XP machine (I know, some people may point out this as being what is 'wrong' but this generation of Windows has always best matched the equipment's purpose and capabilities and it's not going to have an upgraded/regraded OS for other reasons until it actually physically dies), and I've encountered other programs in the past that have apparently changed their compiler (or the same compiler has had a new release update itself) where XP support has been impliclty dropped from the resulting products, so maybe that's the case here.
Don't know whether it's a priority problem to solve. It's not life and death, for myself, as we already mostly have it catching up directly by PIDs for things that fall through to this stage. But it may be something otherwise not known/reported (yet) by fellow sufferers or the developers - unless I missed where they have.
Or there's a really specific problem with this machine's setup (other than that already stated), that I've not discovered. I've got access to other XPs (not normally online even as much as this above one) and even 2Ks (would need some work to even put back on a LAN) that I might test upon next time it's convenient.
And maybe I can even get my recently updated schedule-scraper code to remunge its input into cache-friendly format to bypass 3.22's broken fetching format, though I'd really not yet ever tried to dabble into the source code/script myself at all yet, despite .pl being my scripting of choice.
(Or, I just realised, I could just see what deltas exist between the installed 3.20 resources and the and available 3.22 ones - and manually over-write the differences. Sorry, only just occured to me. Will do if I get the time and it's still a thing needing doing.)
Version 3.22 (and 3.21, when also tried) of the Win32 release fails to install with "[path-and-exe-name] is not a valid Win32 application". Confirmed with multiple download attempts from github via subtly different download methods to try to iron out the usual glitches. The .exe icon is the correct get_iplayer one, in all cases, so seems to be at least partially a valid binary executable and not accidentally stripped to 7bit or something like used to happen in olden times.
Discovered when attempting to update the prior 3.20 install that was suddenly giving the "0 programmes found" error*, that cropped up for Radio (most important for my purposes) and TV; and specifically noted as now solved, before I'd even encountered it and gone looking!
(* - In a separate personal scraping of future radio schedules for interesting programmes to try to listen to live, I had noted the restructured data - I used to search and isolate the data I needed by keying in on the "@CONTEXT" string in the raw html, with my own separate code, then suddenly found it was the second instance! So I imagine that's also related to what broke the get_iplayer cache-building, and has had to be fixed.)
This is on an XP machine (I know, some people may point out this as being what is 'wrong' but this generation of Windows has always best matched the equipment's purpose and capabilities and it's not going to have an upgraded/regraded OS for other reasons until it actually physically dies), and I've encountered other programs in the past that have apparently changed their compiler (or the same compiler has had a new release update itself) where XP support has been impliclty dropped from the resulting products, so maybe that's the case here.
Don't know whether it's a priority problem to solve. It's not life and death, for myself, as we already mostly have it catching up directly by PIDs for things that fall through to this stage. But it may be something otherwise not known/reported (yet) by fellow sufferers or the developers - unless I missed where they have.
Or there's a really specific problem with this machine's setup (other than that already stated), that I've not discovered. I've got access to other XPs (not normally online even as much as this above one) and even 2Ks (would need some work to even put back on a LAN) that I might test upon next time it's convenient.
And maybe I can even get my recently updated schedule-scraper code to remunge its input into cache-friendly format to bypass 3.22's broken fetching format, though I'd really not yet ever tried to dabble into the source code/script myself at all yet, despite .pl being my scripting of choice.
(Or, I just realised, I could just see what deltas exist between the installed 3.20 resources and the and available 3.22 ones - and manually over-write the differences. Sorry, only just occured to me. Will do if I get the time and it's still a thing needing doing.)