Issue with sorting

[Olivier6767]

Hi, I have an issue with the sorting of the m3u and xml file. I have an m3u file that is already sorted properly and I'm trying to get hte xml file sorted in the same order as the m3u. Therefore, I have used the option: "xml_sort_type": "m3u"

However the result is:

• the m3u file gets sorted apparently by the field: group-title !
• the xml file is left in the original order

My goal is to have the m3u file ordered like it originally was, and the xml file to be ordered the same as the m3u. I can provide test files if neded.

Did I misunderstand the sorting function?

Here is my config file: { "m3uurl": "http://myserver.com/file.m3u", "epgurl": "http://myserver.com/file.xml", "groups": [ ".*-----.*" ], "groupmode": "discard", "discard_channels": [], "include_channels": [], "id_transforms": [], "group_transforms": [], "channel_transforms": [], "range": 24, "sortchannels": [], "xml_sort_type": "m3u", "tvh_start": 0, "tvh_offset": 0, "no_tvg_id": true, "no_epg": false, "force_epg": false, "no_sort": false, "http_for_images": false, "preserve_case": false, "outdirectory": "/files", "outfilename": "file_sorted", "log_enabled": true }

Thanks for this awesome tool!

[bebo-dot-dev]

Hi there,

Since you have not specified a sort order for m3u items in your config by specifying an empty "sortchannels": [] array, the default behaviour for sorting m3u items is to fallback to sorting by group and channel names. If you look in the process log I expect that you'll see sorting filtered items alphabetically by group and channel name in there somewhere.

https://github.com/bebo-dot-dev/m3u-epg-editor/blob/master/m3u-epg-editor-py3.py#L639

[Olivier6767]

Hi, Thanks for the explanation, you are correct, it is mentioned sorting filtered items alphabetically by group and channel name in the process log, I overlooked this...

Is there a way to keep the m3u sorted as it was initially, which is by tvg-chno or by tvg-id.

If I usesortchannels, can I specify the field to use, like tvg-chno or tvg-id ?

[bebo-dot-dev]

You can use sortchannels to sort your channels in any way that you'd like, this array only supports channel names though so if you want to use it you would just need to list your channel names in the sortchannels array and the result will be an m3u containing channels sorted in the order that you have specified.

[bebo-dot-dev]

Re-reading what you've said, it sounds like you don't want any sorting to be performed at all. If that's the goal, try "no_sort": true in your config.

[Olivier6767]

I don't need/want to sort the m3u file, it is already cleanly sorted. However I would like to sort the xml file to match the order of the channels in the m3u file. Specifying channel names would be a pain since the list is 300+ channels and can evolve (I maintain the channel list and epg mapping with xTeve). I tried the no_sort option, but it also applies to the xml file, therefore the xml file does not get sorted either...

I think the no_sort option should only apply to the m3u file (maybe call it no_sort_m3u)? For the xml sorting, there is already the xml_sort_type = "default", which disables sorting of the xml... This would allow more precise control of the sorting for the m3u and the xml file.

Just a suggestion... Thanks!

[bebo-dot-dev]

This sounds a bit odd tbh, the idea of "no_sort": true is that m3u items should be completely untouched so far as sorting goes which (in theory) should result in a newly generated m3u file that is in the same order as the original m3u is in. If this works as it should, then specifying xml_sort_type = "m3u" (in theory) should then result in a newly generated epg xml file with a sort order that follows the m3u items. If this works as it should, it sounds like it does what you want it to do. If it doesn't work like this.. sounds like a bug.

[bebo-dot-dev]

I tested with "no_sort": true and xml_sort_type = "m3u" and it worked out as expected as described in my last comment. The resulting m3u item sort order remained untouched and the epg xml sort order followed m3u item sort order. Seems to work, seems to meet the

My goal is to have the m3u file ordered like it originally was, and the xml file to be ordered the same as the m3u.

..requirement.

[Olivier6767]

Ok, I found what the issue is: In the resulting XML file, the <programme> entries are sorted correctly, following the order of the channels in the M3U file. However, at the beginning of the XML file, there is the sections containing the <channel> entries, and these entries are not ordered. They left as they were in the original file. The Web EPG viewver I'm using seems to list the channels in the order of this <channel> section, this is why I wanted to re-order to XML file. Should this secrtion be re-ordred as well if specifyingxml_sort_type ? Is this doable?

[bebo-dot-dev]

To be accurate the <channel> elements in the epg xml file do follow the order of the m3u items in the m3u file when xml_sort_type = "m3u" is specified. The mapping between items in the m3u file and channels in the epg file is where a <channel> id attribute matches an m3u item tvg-id attribute.

There's nothing wrong here as far as I can see.

My goal is to have the m3u file ordered like it originally was, and the xml file to be ordered the same as the m3u.

..appears to be doable.

[Olivier6767]

Well, for me the <channel> elements don't get re-ordered based on the m3u channel orders when using xml_sort_type = "m3u". The <channel> elements are left in the same order as the original xml file (random) but the <programme> entries do get sorted based on the m3u channbel order. I can try ot prepare a small test file if needed.

[Olivier6767]

I created the following test files:

• test.m3u
• test.xml
• test.json (config file)

The <channel> elements don't get sorted. The <programme> elements get ordered correctly.

https://we.tl/t-OSDhFGmBbY

[bebo-dot-dev]

Thanks for that, it was very useful for reproducing the issue. It is a bug, one fix coming up soon.

[bebo-dot-dev]

There's a new branch here: https://github.com/bebo-dot-dev/m3u-epg-editor/tree/xml_sort_type_fix that contains the fix

Give that a go.

[Olivier6767]

Works perfectly ! Thank you very much!

[bebo-dot-dev]

Great to hear, no problem, thank you for finding the bug. I'll merge the fix.