I think I have an easy code fix, trying to replicate the problem first
old:
if( @{ $data->{schedule}} ) {
new:
if( $data->{schedule} && @{ $data->{schedule}} ) {
Do you want to fix it or should I? (I don't remember if you're the official maintainer). Would be nice if OP mentioned which 10 stations he was grabbing. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did do some work on this grabber but I only had a trial subscription, which has long since expired, so I can't test any more. So if you wouldn't mind doing it, that would be cool :-)
I'd go with your "new" option I think.
It would however be good to know what was actually returned in the JSON content, so we could see exactly why it returned 'no error but no schedule' !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If the http fetch fails, it prints a message but tries to parse the output anyway. At least that's what happens with the get_program_details... which I also fixed.
I got this, but still haven't been able to replicate the problem though my full-channel grab is still running.
(BTW, this is not that grabber with the subscription)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One of your channel-days is returning no data. Try asking for fewer days or playing with the channels selected to see if you localise the problem.
Still not a great way for the grabber to handle it.
Agreed; I am trying to identify if the problem is with the OP's channels not being up-to-date, or if it's a transient problem with the data source.
I think I have an easy code fix, trying to replicate the problem first
old:
if( @{ $data->{schedule}} ) {
new:
if( $data->{schedule} && @{ $data->{schedule}} ) {
Do you want to fix it or should I? (I don't remember if you're the official maintainer). Would be nice if OP mentioned which 10 stations he was grabbing. :)
I guess a better solution would be ref($data->{schedule} eq 'array', but that's probably overkill.
I did do some work on this grabber but I only had a trial subscription, which has long since expired, so I can't test any more. So if you wouldn't mind doing it, that would be cool :-)
I'd go with your "new" option I think.
It would however be good to know what was actually returned in the JSON content, so we could see exactly why it returned 'no error but no schedule' !
If the http fetch fails, it prints a message but tries to parse the output anyway. At least that's what happens with the get_program_details... which I also fixed.
I got this, but still haven't been able to replicate the problem though my full-channel grab is still running.
(BTW, this is not that grabber with the subscription)
Ah right, sorry I gets confoozed ;-)
fix committed.