Special chars in group names don't seem to work

[timhobbs]

I have a couple group titles like "24/7" or "this & that" and the groups don't get picked up. I can only assume it has to do with the / and & chars. It looks like the regex should match these chars no problem, but I have multiple group titles with the / and none of them get picked up.

[bebo-dot-dev]

hmm sounds odd, thanks for the heads up. I'll run some tests to see if I can reproduce it

[bebo-dot-dev]

I think I'll need further information about your m3u file, it's contents and how you're calling the script to understand what this problem is because I've not been able to reproduce this.

My steps to reproduce were to start with a valid m3u file on disk, edit one channels' group-title attribute from "United Kingdom" to "United/Kingdom" and then call the script like this:

python /home/joe/Dev/git_repositories/m3u-epg-editor/m3u-epg-editor.py -m="file:///home/joe/Dev/git_repositories/m3u-epg-editor/original.m3u8" -e="http://vaders.tv/p2.xml.gz" -g="'united/kingdom'" -r=12 -t=100 -d="/home/joe/Dev/git_repositories/m3u-epg-editor" -f="mini"

The end result was a reduced m3u file containing that one channel and an epg xml file containing data for that one channel as expected.

[bebo-dot-dev]

Thinking on some more about this, I suppose it could be possible that the shell you're using to call the script might be stripping out or escaping special characters like / and &. That said this does work fine in linux as demoed in my last comment.

[timhobbs]

Sorry it took so long.

I finally had a look at things and added some logging, and it turns out the group naming is fine. The issue is actually that a valid M3uItem is assumed to have a tvg-id value, but there are many things that don't have them - like live events or 24/7 channels. I removed that line from the is_valid check and it works as expected now.

[bebo-dot-dev]

No problem. Ah yes this makes sense now:

https://github.com/jjssoftware/m3u-epg-editor/blob/master/m3u-epg-editor.py#L55

This issue has been raised by someone else in the past an earlier version of the script:

https://github.com/jjssoftware/m3u-epg-editor/issues/9#issuecomment-392680932

As it stands this is by design behaviour but I might add a switch to enable channels with a blank / non present tvg-id attribute to be included in the output m3u in the future. I happily accept reasonable pull requests too ;)

I'm going to close this one now because it's not really a bug, it's by design behaviour and you appear to have found yourself a local workaround for the moment.

[spec1re]

Hi, same issue here.

My workaround is downloading the m3u list with wget first and find and replace all tvg-id="" with tvg-id="dummy", this way m3u-epg-editor.py can pickup all channels.

It would be nice to have a command line switch like:

--no-tvg-id Ignore missing or empty tvg-id tags

and optional

--no-epg Skip epg processing

This would make m3u-epg-editor.py compatible with any IPTV provider.

Thanks.

[bebo-dot-dev]

I like your suggestions @spec1re. Your comment is a good example of a dry succinct feature request.

It's probably fair to say that it's now clear this is an issue that affects a fair few people. We have this issue that contains a couple of people affected and the original that showed a few other people affected.

On that basis I'm going to reopen this, switch this to a feature request and take a look at implementing your suggestions.

[spec1re]

@jjssoftware thank you very much, your work is very much appreciated. 👍

[bebo-dot-dev]

Hopefully that should do it, two new optional arguments have been introduced:

--no_tvg_id / -nt and --no_epg / -ne

There's no need to specify any value for these two Boolean type arguments, the presence of these will mean they will be treated as "True" and they will work as described in the help:

--no_tvg_id, -nt      Optionally allow channels with no tvg-id attribute to be considered as valid channels
--no_epg, -ne         Optionally prevent the download of and the creation of any EPG xml data

If they're not there, the script will continue to work as it always has done.

The readme is also updated.

Please feel free to test / let me know if you see any issues.

Many thanks

[spec1re]

Wow that was fast!

It looks like working fine here, no issues so far. Processing around 15.000 channels (incl. VoD) is just 2 seconds now.

Just one question more, how can I keep the original sort order of the channels? (If needed I can open a new issue.)

Thanks!

[bebo-dot-dev]

Sounds good @spec1re , thanks for the feedback.

So far as sorting goes there's a assumption at the moment that some sort of sorting is desired even if no specific custom sort order was specified via the --sortchannels / -s argument. When no custom sort order is supplied, channels are sorted into channel group / channel name order.

You could go down the road of adding a custom sort order to get your channels back into the same exact order they were originally in but I think you might be after a feature where no sorting is applied at all? If so I guess I could take the same approach and introduce some sort of --no_sort / -ns override argument.

[spec1re]

--no_sort / -ns would be an excellent option. My m3u list has so many channels, custom sorting would take ages.

[bebo-dot-dev]

ok no problem I'll take a look later this evening. Don't worry about creating another issue, I can just reference this one.

[bebo-dot-dev]

ok @spec1re see how you go with: --no_sort / -ns

As per the previous earlier two, there's no need to specify any value for this Boolean type argument, the presence of it will mean it will be treated as "True" and it will work as described in the help:

--no_sort, -ns        Optionally disable all channel sorting functionality

If not there, the script will continue to work as it always has done so far as sorting / default sorting goes.

The readme is also updated.

Please feel free to test / let me know if you see any issues.

Many thanks

[spec1re]

This is perfect and works great!

Thanks a bunch! :)

[bebo-dot-dev]

No problem at all, decent features will benefit everyone and hopefully prevent future issues being raised.