cc: @higuita

Not sure why some checks failed, but my tests show that this is working fine

Not sure why some checks failed, but my tests show that this is working fine

Looks like transient network and/or container issues, rather than issues with the XMLTV code.

So right now the channel.list needs to be located in the same place as the grabber... but if we execute the grabber with full path from other directory, it fails to find the channel.list

so we have 2 options:

1. detect the grabber path and add that path to the channel.list

use File::Basename;
my $dirname = dirname(__FILE__);
my $input_file = $dirname . '/channel.list';

2. add a new option for changing the channel.list location

So what you think would be the best solution

Some of the other grabbers use $ENV variables for this. e.g.

sub get_default_dir {
	my $winhome = $ENV{HOMEDRIVE} . $ENV{HOMEPATH}
			if defined( $ENV{HOMEDRIVE} ) and defined( $ENV{HOMEPATH} );
	my $home = $ENV{HOME} || $winhome || ".";
	return $home;
}
sub get_default_cachedir {
	return get_default_dir() . "/.xmltv/cache";
}

Maybe something like that?

@higuita decided to go with your solution, seems to be the cleanest one. nice catch this one :)

@honir your proposal is meant for the cache dir located in the home path, this is file is not generated from within xmltv but bundled with it, otherwise this would have been a better solution.

thanks for all input.

your proposal is meant for the cache dir located in the home path

Not necessarily -- that was only an example -- I use it also for bundled files (in ~/.xmltv )

And you can, of course, alter the ENV variables to anything you like :-)

Not sure why some checks failed, but my tests show that this is working fine

Looks like transient network and/or container issues, rather than issues with the XMLTV code.

There were various issues with the github actions workflow that had nothing to do with this particular PR (the build workflow was failing in some steps for everyone, even the weekly scheduled tests).

I believe the workflows now work properly, so future PRs (or existing ones rebased) should run without build workflow errors, until the next time some distro changes something important (and there is always a next time).

@garybuhrmaster thanks, can the workflows be re-triggered ? I couldn't find ways to do it on my own.

@garybuhrmaster thanks, can the workflows be re-triggered ? I couldn't find ways to do it on my own.

If you rebase your branch to the current master and push it should run with the new workflow recipes.

ready to be reviewed :) thanks