search

Threadfin / Threadfin

an M3U proxy for Kernel/Plex/Jellyfin/Emby based on xTeVe
MIT License
572 stars 42 forks source link

Channel Names with Apostrophe's are Still Broken #259

Closed bweezy21 closed 1 month ago

bweezy21 commented 1 month ago

Please first read the documentation. Problems affecting the client, e.g. Plex or Emby should be reported there in the forum.

Describe the bug Channel names containing apostrophes are broken. They now get named the same name as the previous good (non apostrophe) channel name.

Server (please complete the following information):

To Reproduce Steps to reproduce the behavior:

  1. Import M3U with channel names containing apostrophes
  2. View mapping
  3. See duplicate names

Expected behavior Channels named correctly

Screenshots If applicable, add screenshots to help explain your problem.

channel 30177 should be "Let's Make a Deal" image

Desktop (please complete the following information):

Additional context Add any other context about the problem here. Apostrophes were broken before where they would cut the name off. Now it just throws the entire name away and uses the name from the previous channel.

bweezy21 commented 1 month ago

playlist.txt epg.txt

Here are some example m3u and xml files. Had to rename them for github.

The screenshot above is from an m3u and xml file previously parsed through channelsDVR then piped into threadfin. The attach files are directly from the source which is a container I host locally for pluto channels. This one is even worse than the screenshot above. Things definitely go very very wrong parsing the channels after there is an apostrophe.

Fyb3roptik commented 1 month ago

Your M3U is using invalid apostrophes. It is using U+2019 and should be using U+0060. You can also urlencode it. You can make sure Ignore Non ASCII is checked and it SHOULD ignore it.

bweezy21 commented 1 month ago

Your M3U is using invalid apostrophes. It is using U+2019 and should be using U+0060. You can also urlencode it. You can make sure Ignore Non ASCII is checked and it SHOULD ignore it.

The last time i reported this in february (this is now the 4th time to get you to take it seriously) https://github.com/Threadfin/Threadfin/issues/172 another commenter pointed out how the code is actively removing these characters. It is not a matter of non ascii (that setting is enabled by the way). More importantly there is not a spec for m3u that would justify the code's behavior of removing valid tags after an apostrophe.

Why is it so difficult to import a valid m3u file containing apostrophes and test to see why an how the code is removing them? both with the ascii setting enabled and disabled. The m3u I provided is valid and is accepted and parsed properly everywhere except threadfin.

You're enforcing a non existent restriction on m3u's. It's just not correct.

Furthermore, the ACTUAL issue is tht the parser is replacing apostrophes (single quotes) with double quotes (") which is causing a bug in the parser.