Enhancement: Better Remapping Capability

[Croq360]

The current remapping that's implemented, while useful and helpful, could be improved. My suggestion is supporting a way that users could have control over the channel numbers (and possibly displayed names), and the ability to deactivate channels you don't want to have available. Emby supports sorting channels by name in the guide, which is nice, but removing a channel from the guide is not very straight-forward, and if you ever change your listings, you have to go back in and do it again. Plex allows you to remove channels from the guide in their manage Live TV & DVR page, but in the guide, you can only sort by channel number, no other option.

By giving more control to users on channel numbers/names, and activating/deactivating channels, you could have one place to manage all that in locast2tuner.

Some people might ask, "Why not just use xTeVe?" I am actually using that now. The issue there is that if you want to have both Plex and Emby supported at once, you'll likely have to run two instances of xTeVe. The reason for this is xTeVe's buffer capability, the default is to just hand the original m3u stream over to the client (like Plex/Emby) to play. This works great for Emby, but Plex doesn't support that. You could switch to have xTeVe do the buffering, but then you need to configure Emby to use locast2tuner in HDHR mode so the buffering will work, otherwise you can't play streams in Emby. Or you set up two instances of xTeVe like I have done, one with buffering, one without. Point Plex at the buffering one and Emby at the non buffering one. The problem here is that now you have to manage two separate channel remappings.

My proposal is for locast2tuner to offer a remap JSON file that allows you to go in and edit to your liking, then reference that remap when you run locast2tuner to get the numbers/names you want. While it would be nice to be able to edit these values through some tool in locast2tuner, if that's not possible, then having a way to get a starter file would be good, something like going to localhost:6077/remap.json. Save that file off, then edit, save, and point locast2tuner to use your modified list of channels.

{
  "channel.1571434910068": {
    "original-name": "KTVK (Phoenix)",
    "remap-name": "AZ Family (Phoenix)",
    "original-number": "3.1",
    "remap-number": "3",
    "active": true
  },
  "channel.1571434910374": {
    "original-name": "CBS (Phoenix)",
    "remap-name": "CBS (Phoenix)",
    "original-number": "5.1",
    "remap-number": "5.1",
    "active": true
  },
  "channel.1571434911228": {
    "original-name": "PBS (Phoenix)",
    "remap-name": "PBS (Phoenix)",
    "original-number": "8.1",
    "remap-number": "9.1",
    "active": true
  },
  "channel.1571434911800": {
    "original-name": "FOX (Phoenix)",
    "remap-name": "FOX (Phoenix)",
    "original-number": "10.1",
    "remap-number": "7.1",
    "active": true
  },
  "channel.1571434912373": {
    "original-name": "NBC (Phoenix)",
    "remap-name": "NBC (Phoenix)",
    "original-number": "12.1",
    "remap-number": "6.1",
    "active": true
  },
  "channel.1571434913084": {
    "original-name": "ABC (Phoenix)",
    "remap-name": "ABC (Phoenix)",
    "original-number": "15.1",
    "remap-number": "4.1",
    "active": true
  },
  "channel.1571434913506": {
    "original-name": "COURT (Phoenix)",
    "remap-name": "COURT (Phoenix)",
    "original-number": "15.4",
    "remap-number": "145.1",
    "active": false
  },
  "channel.1571434916392": {
    "original-name": "CW (Phoenix)",
    "remap-name": "CW (Phoenix)",
    "original-number": "61.1",
    "remap-number": "8.1",
    "active": true
  }
}

In the above example, I have disabled Court TV. I have renamed KTVK to "AZ Family" (how it is better known here). And I have renumbered ABC, CBS, NBC, FOX, CW, and PBS to 4.1, 5.1, 6.1, 7.1, 8.1, and 9.1 respectively. That gets AZ Family up top where I want it, followed by all of the network channels, and I could renumber all the remaining channels to my liking as well.

The key for each entry in the JSON data is the unique channel id for that channel (which should not be changed).

Regarding the "remap-name" and "remap-number", maybe to make things easier, they just should stay empty unless you actually want to change something (e.g., if you did this, then the entry for CW would have "remap-name": "", and locast2tuner would not rename it in that case). Just an idea.

In the event any new channels were to come along, they'd just default to no rename/renumber and be put wherever they happen to appear. Perhaps having the logging flag that could key a user to know that they have some new channels to deal with. Not sure how to deal with channels getting removed, I assume that happens. Also, I don't know if Locast would ever go through and change the channel id's, but I guess if they did, the user would have to deal with those too.

I don't know whether the current remapping process should remain (in case you have users that just want that simplicity), or if this new process replaces the current one.

[Croq360]

Last night, I was tinkering around with how to render the remapping info on a page where you could edit it. I came up with rough prototype, just to see if it could work.

I found a package called Tabular (tabular.info), downloaded it, created the attached HTML file and put it in the root of the Tabular folder. If you do that, you can load the HTML file take my snippet above and save that to a JSON file, then load that from the webpage (Choose File, then Import), you'll see a table rendered that you can edit. Every column can be sorted on and all columns are editable except for channel ID.

Notes:

• The JavaScript code creates a local array of dictionaries to feed into Tabular. The Tabular package couldn't make sense of what is above.
• There is no code in there to save the JSON to a file (another transformation back to the format above would be needed before you do that) - it was way too late at night to try and tackle that.
• This approach is more intended to be an inspiration or starting point. Whether it's ultimately included in the web interface for locast2tuner (which seems like the logical place to put it, in my opinion), or winds up being a separate tool is to be determined.
• The attached file has a TXT extension - change it to HTML to try it out.

test.txt

[Croq360]

I'll see if I can get some time to tinker some more on this tonight and at least get it set up to support the full round trip (Read in JSON->HTML edit->Write out JSON). I can work on "prettying it up" after that... :)

[Croq360]

@wouterdebie - for this approach, are you thinking the editing of the remapping data would be something you could do inside of the main web interface (like 127.0.0.1:6077/remap, have that load your current remapping, if any, and you could edit it). The tricky part might be on how to save the remap data once you're done. Also, do you think using the TOML format would be better or sticking with something like JSON?

In order to use the tabulator features, you need to feed it an array of dictionaries, so you'd need to change the above structure to be an array, and put the channel ID in each of the dictionaries, something like "channel-id": "channel.12345". Then tabulator can display it quite nicely and allow you to edit to your liking. Once you're done, it'd need to convert back to the original format and then save that to JSON (or TOML) file.

Alternatively, the remap format we use could already be an array of dictionaries. When you read in that data, you do a quick lambda expression to convert it to the format above to make it easier to work with in the actual remapping that locast2tuner would do. Going that route would make the remap edit process easier, but you'd have the bit more complication in locast2tuner to do that conversion as you start your remap processing.

For example, in Python, let's say I had an array of dictionaries in a variable called remap. The structure of each item is something like this:

[
  {
    "channel-id": "channel.1571434910068",
    "original-name": "KTVK (Phoenix)",
    "remap-name": "AZ Family (Phoenix)",
    "original-number": "3.1",
    "remap-number": "3",
    "active": true
  }
]

To get that into the format that I originally posted, dictionary of dictionaries, with a key of the channel id, I could just put it into another variable using a call like this:

remapDict = {d["channel-id"]: d for d in remap}

Note that you'd still have the "channel-id" item in each dictionary, but that's probably okay for your processing to apply the remaps.

{
  "channel.1571434910068": {
    "channel-id": "channel.1571434910068",
    "original-name": "KTVK (Phoenix)",
    "remap-name": "AZ Family (Phoenix)",
    "original-number": "3.1",
    "remap-number": "3",
    "active": true
  }
}

[Croq360]

Okay, I have put together a bit more functional version of the remapping editor. It should at least give you an idea of what it can do, but there are more things I want to try out (see below).

As a reminder, you need to download the tabulator package from tabulator.info, then save the attached remapEditor.txt as remapEditor.html in the root folder for tabulator.

You would need the channel remapping information in the format in my first post. Paste that into the JSON data area.

Click on Copy to Table to create the tabulator table on the right. Note that you can reorder on any of those table columns, but only the remapped name/number and active flag are changeable for each item.

Once you've made your edits, click Copy to JSON to copy your edits into that JSON data area.

At this point, you could copy the text in that JSON window and save those changes to remap.json (or something like that).

Note that obviously, locast2tuner doesn't support this yet. I'd like to try and figure out a way to load the JSON remapping data from a file you pick (should be easy to do), and then save your changes to that file (not sure if you can do that directly from an HTML/JavaScript page, you can certainly save a file, just not sure you'd be able to overwrite an existing file).

remapEditor.txt

[wouterdebie]

Cool! I'll start with just having a remapping file that you can specify on the command line and then think about how the UI should work. As you mention, one of the things is how to save data. Do we want this in just a json file or do we want to use some other storage mechanism?

[Croq360]

I was thinking about that too. Could locast2tuner manage the remapping internally and just use something similar to what I've put together to manage the remappings through the web interface?

I mean what I have provided can work, just more of a "manual" process to load and update the data than I'd like.

Though maybe that's not the best idea to keep it "internal" either. Having access to the JSON directly would allow you more ability to edit things if you wanted. Like doing a bulk change if you wanted to change "(Phoenix)" to "(AZ)" or something like that.

[wouterdebie]

@Croq360 What do you think in general the behavior should be? Do we keep --remap as well, or do we replace this with the remap file? In case we keep it, what would you expect to happen? Remap first with --remap and then apply the mapping from the file? Or do we only apply the file?

[Croq360]

Maybe we could leave the current approach in there, using "--remap" to tell locast2tuner that you want to remap. Then there "--remap-file=remap.json" (or whatever the right format is). If that's provided, then you're telling the program to remap based on the data in that JSON file instead of using the standard way. I suspect that there are at least some people that like the simplicity of the current approach, so I'd hate to take that away from them.

[wouterdebie]

@Croq360 cool. I just pushed a proof of concept. Would you mind checking this out? Right now --remap takes precedent over --remap_file. I also changed the format of the json a bit, since I wanted to keep using the correct terms. With --remap we map the channel number and the call_sign, so I'm referring to this here as well. The original_channel and original_call_sign are purely for documentation and unused in the code. Lastly, I removed the (city) from the remap, since that's added by the muliplexer as a last step, rather as part of the remap.

Let me know what you think and if this works as expected.

[Croq360]

Sure, I'll grab that and take a look. Any reason why I couldn't config the test version to run on a different port and keep my current version running? Assuming of course that I don't try to do too many streams at once... :-)

[Croq360]

I cloned the branch you created for the remap PoC, but when I went to build it with "cargo build", I got the following errors:

   Compiling unix_socket v0.5.0
error[E0433]: failed to resolve: could not find `unix` in `os`
  --> C:\Users\Rutabaga\.cargo\registry\src\github.com-1ecc6299db9ec823\unix_socket-0.5.0\src\lib.rs:19:14
   |
19 | use std::os::unix::ffi::OsStrExt;
   |              ^^^^ could not find `unix` in `os`

error[E0433]: failed to resolve: could not find `unix` in `os`
  --> C:\Users\Rutabaga\.cargo\registry\src\github.com-1ecc6299db9ec823\unix_socket-0.5.0\src\lib.rs:20:14

And then tons more errors (presumably related to the above). Any ideas what I'm missing?

Same results if I run with "cargo build --release". The website https://docs2.w3cub.com/rust/std/os/unix/ffi/trait.osstrext/ seems to suggest that maybe it's unix only?

[wouterdebie]

Ah yes.. It seems like slog-rs includes syslog which is unix only.. Let me see if I can find a way to omit that for windows.

[wouterdebie]

@Croq360 I can't test this because I don't have windows, but could you try to compile from the fix_windows branch? This doesn't include the remapping stuff, because I want to make sure the windows build is fine first.

[Croq360]

Sure, will let you know.

[Croq360]

@wouterdebie - Okay, it compiled fine, and I was able to load up my channels into NextPVR. Also, I did the "logfile" option and it appeared to be logging to that file. So, it appears to be good to go.

[wouterdebie]

Awesome, thanks for testing! I'll merge this tomorrow and continue the work on the remap stuff.

On Mon, Apr 19, 2021, 18:11 Croq360 @.***> wrote:

Okay, it compiled fine, and I was able to load up my channels into NextPVR. Also, I did the "logfile" option and it appeared to be logging to that file. So, it appears to be good to go.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wouterdebie/locast2tuner/issues/36#issuecomment-822848015, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABKABV5D4HZPEC5VBFFEB3TJS2DNANCNFSM424DFGZA .

[Croq360]

I managed to get the files merged on my end and noticed an issue.

1. Channels that I have marked as '"active": false' are still showing up in the listings. I would have expected them to be excluded.
2. For inactive channels still showing up, they show up in the guide with their original number. Of course, if they were deactivated and not included in the list that locast2tuner sends when you load up 127.0.0.1:xxxx/tuner.m3u, that wouldn't matter too much.

I'll keep looking at it, but that's the only problem I'm seeing so far.

[wouterdebie]

I see now. What about channels you haven't specified in the mapping file? Should those be included or excluded?

[Croq360]

I think if a channel comes in that's not covered by the remapping, it should just be included as-is. You can theoretically dump a new remap list from the web interface that includes those channels and remap/deactivate accordingly, then save off your changes.

So, the default action should be to make the channel active and don't remap it.

[wouterdebie]

Cool, thanks!

[wouterdebie]

@Croq360 I just updated the remap_file branch (force pushed by accident, so the repo might be somewhat screwed up). This should do what you mentioned. Mind testing this out?

[Croq360]

Sure, no problem. It'll be a bit later in the day though - gotta do some real work during work hours. :-)

[wouterdebie]

haha! no rush! Thanks for the immense help!

[Croq360]

I couldn't resist, did a bit of playing. I did notice a side-issue. If you set a logfile name and the directory doesn't already exist, Rust will throw a "panic". Do you want me to create a separate issue on that?

[wouterdebie]

haha, nice! You could make an issue of that, but I don't think locast2tuner should be responsible for making any directories in that case. It does make a directory for it's own cache, but for logging, I'm not so sure tbh. Right now in the ubuntu/debian packages, that is something the package takes care of.

That said, the error messages might be a bit nicer..

[Croq360]

That's ok then, easy enough to create the directory...

I did find an issue with the call signs when the number isn't using the ".1" type numbering. Here's an example.

remap.json file:

  "channel.1571434910068": {
    "original_call_sign": "KTVK",
    "remap_call_sign": "KTVK",
    "city": "Phoenix",
    "original_channel": "3.1",
    "remap_channel": "3",
    "active": true
  },

tuner.m3u result:

#EXTINF:-1 tvg-id="channel.1571434910068" tvg-name="3 KTVK" tvg-logo="https://static.locastnet.org/logo/Phoenix/KTVKDT.png" tvg-chno="3" group-title="Phoenix", 3 KTVK (Phoenix)
http://127.0.0.1:6188/watch/1571434910068.m3u

The tvg-name value should be "KTVK" instead of "3 KTVK".

Note that it does the same thing if I change the value in remap-call-sign. So if I changed the name to "AZ Family", the channel name I wind up with is "3 AZ Family".

[Croq360]

A question in addition to issue above:

Have you put together the page for webserver to provide the current set of channels? If it doesn't have any remap info for a given channel, I guess it should just output a record where original and remap values are the same, and as discussed before, making active = true. I'm guessing this is not available yet. To get people started with a remap file, we'll need to have a way to get a baseline that they can start editing (they wouldn't really have a way to be able to know the channel id values for example) - plus it'd be a good way to see if there are any problems once they have made changes and loaded the new remaps.

[wouterdebie]

Sorry, I forgot to mention this. You can use /map.json to give you the current mapping (even if there is none). One thing I realized is that it probably breaks things, because it will interpret the ones that have empty fields as well..

[Croq360]

I checked map.json with my fuller set of remaps. I did notice a problem. Shouldn't this:

  "channel.1571434910068": {
    "original_call_sign": "3.1 KTVK",
    "remap_call_sign": "103 AZ Family",
    "original_channel": "3.1",
    "remap_channel": "103",
    "city": "Phoenix",
    "active": true
  },

Come through like this?

  "channel.1571434910068": {
    "original_call_sign": "KTVK",
    "remap_call_sign": "AZ Family",
    "original_channel": "3.1",
    "remap_channel": "103",
    "city": "Phoenix",
    "active": true
  },

And what do you mean, referring to "the ones that have empty fields"?

[Croq360]

I think I see what you mean by "empty fields". I tried running locast2tuner with no remapping at all and got some empty values. Here's an example:

  "channel.1571434910068": {
    "original_call_sign": "3.1 KTVK",
    "remap_call_sign": "",
    "original_channel": "3.1",
    "remap_channel": "",
    "city": "Phoenix",
    "active": true
  },

As mentioned above, I think "3.1 KTVK" for "original_call_sign" should be just "KTVK".

Also, the "empty fields" touches on something I mentioned earlier. If you don't want to remap a name or number, shouldn't it be okay to just leave it blank? Then locast2tuner could just not remap it. It'd still need to handle the active flag (I could see a situation where you might not rename/renumber something, but want to exclude it). Like in my case, I'm not really interested in Univision, so the only thing I'd probably do on that one would be to mark it as active=false.

[wouterdebie]

A few updates and comments:

• I've added the additional field remapped to the json. This indicates if a remap should actually be applied. This allows you to dump the json and feed it to locast2tuner. This prevents us from having empty fields because of the remap.
• Regarding the call sign: The callsign always includes the channel number. This is data we get from Locast. In certain places (e.g./ tuner.m3u) we only use the part after the channel name, but this is a separate operation. This is somewhat confusing, and I might change this, but this would require a bit more work. Besides that "3 KTKV" is not a valid call sign, since they always shoud be in the format X.Y NAME, where X and Y are integers.

[wouterdebie]

Aight, I went ahead and removed the channel number from the call sign when building the stations. This in general makes more sense. @Croq360 could you test this? I walked through the epg.xml, tuner.m3u and lineup.json and things seem like they need to be as far as I can see.

[Croq360]

Thanks for the quick updates, we're getting there! :-)

I'll check out the changes with the "remapped" value. It's a shame we can't just have the logic be "if there's a value in either of the remap fields, then it's remapped, otherwise it's not". With the implementation you have here, does that mean you'll have to also set the "remapped" value if you put something in the other two fields? And how does it interact with the "active" flag? If I don't change anything, but set "active" to false, is that channel considered to be "remapped"?

If we need that other field, then maybe I can figure out a way to have tabulator set the "remapped" automatically conditional on other changes.

About the callsign. If that's the situation and it includes the channel number, that's fine, but I would suggest then that we change that field in the remapping to be just the name then. Otherwise, when you remap, you're going to have to update the channel number in both "remap_call_sign" and "remap_channel", doubling the amount of work you need to do. Since the callsign is basically a concatenation of the channel number and name, it would be ideal if for remapping, you could change those two items independently. Also, what are your thoughts on leaving the remap values blank if you're not changing one or the other. The logic would need to be able to handle those situations.

For example, if I wanted to rename KTVK to "AZ Family" but not change the channel number, I would leave the "remap_channel" value blank, but would change the "remap_call_sign" to "AZ Family" (or use "remap_name" if you're agreeable to what I mentioned in the above paragraph about separating out channel/name from callsign for easier remap editing).

Lastly, on the channel numbers, I think just an integer number should be allowed in remaps. For example, I know that xTeVe's default is to renumber starting at 1000, then 1001, 1002, and so on. No decimal point. And their "tuner.m3u" equivalent for them gives you this for KTVK, which is working without issue in both PMS and Emby. The whole X.Y thing was done when they changed to digital broadcasts, but for flexibility, if it's not too hard to support, I think integer numbers could be useful to some people (like maybe they want to number things like xTeVe does).

#EXTINF:0 channelID="x-ID.0" tvg-chno="3" tvg-name=" KTVK (Phoenix)" tvg-id="3" tvg-logo="https://static.locastnet.org/logo/Phoenix/KTVKDT.png" group-title="Phoenix", KTVK (Phoenix)
http://127.0.0.1:6099/stream/2ae670b3178dc4347b907c07c3ffdf1b

Locast2Tuner has this:

#EXTINF:-1 tvg-id="channel.1571434910068" tvg-name="KTVK" tvg-logo="https://static.locastnet.org/logo/Phoenix/KTVKDT.png" tvg-chno="3.1" group-title="Phoenix", KTVK (Phoenix)
http://127.0.0.1:6088/watch/1571434910068.m3u

One other note here... Note that the "tvg-name" value in xTeVe has a space in front of it. I think that is due to the channel name at the end of the first line having a space after the comma but before the channel name. So, "group-title="Phoenix", KTVK (Phoenix)" instead of "group-title="Phoenix",KTVK (Phoenix)". That's the only place I can think of that the space in front of " KTVK" could be coming from. In digging around on the internet, I see both ways being used, with space and without, and I don't see a definitive specification. Clearly xTeVe is expecting no space (which might be an issue on their side). So I don't think there's necessarily anything to change in locast2tuner, just something I observed.

[wouterdebie]

It's a shame we can't just have the logic be "if there's a value in either of the remap fields, then it's remapped, otherwise it's not". With the implementation you have here, does that mean you'll have to also set the "remapped" value if you put something in the other two fields? And how does it interact with the "active" flag? If I don't change anything, but set "active" to false, is that channel considered to be "remapped"?

I'm not a big fan of implicit behavior. An empty string should not mean "don't do anything" and it makes cases where you remap the call sign, but not the channel much harder, since we'd have to sprinkle checks for the remapped fields everywhere. I rather have the user state "I would like to remap this channel" (aka remap: true) before anything else. And yes, this means that you'd have to set remap: true when you want to deactivate a channel.

About the callsign. If that's the situation and it includes the channel number, that's fine, but I would suggest then that we change that field in the remapping to be just the name then. Otherwise, when you remap, you're going to have to update the channel number in both "remap_call_sign" and "remap_channel", doubling the amount of work you need to do. Since the callsign is basically a concatenation of the channel number and name, it would be ideal if for remapping, you could change those two items independently.

Yeah, so I just changed this in my last update to the branch. The call sign does not include the channel number anymore.

For example, if I wanted to rename KTVK to "AZ Family" but not change the channel number, I would leave the "remap_channel" value blank, but would change the "remap_call_sign" to "AZ Family" (or use "remap_name" if you're agreeable to what I mentioned in the above paragraph about separating out channel/name from callsign for easier remap editing).

Again, I don't really like implicit behavior.. I would like to have the user fill in the remapped channel as well in case a remap needs to happen. Having a blank value meaning "use the original value" is not explicit enough for me..

Lastly, on the channel numbers, I think just an integer number should be allowed in remaps. For example, I know that xTeVe's default is to renumber starting at 1000, then 1001, 1002, and so on. No decimal point. And their "tuner.m3u" equivalent for them gives you this for KTVK, which is working without issue in both PMS and Emby. The whole X.Y thing was done when they changed to digital broadcasts, but for flexibility, if it's not too hard to support, I think integer numbers could be useful to some people (like maybe they want to number things like xTeVe does).

I hear you. This should now be possible, since the channel number is no longer part of the callsign.

One other note here... Note that the "tvg-name" value in xTeVe has a space in front of it. I think that is due to the channel name

I see. I don't think that's correct, but probably has something to do with they way they parse the call sign. (Besides that, they have #EXTINF:0, but technically it should be #EXTINF:-1, because we're dealing with an infinite stream). According to the documentation I found, there should be a space after the comma in an #EXTINF line, so this seems an issue on their side.

[Croq360]

Noted on your comments regarding implicit behavior. I'm fine with that. However, if someone is starting fresh on remapping, now they'll have to copy values from original to remap for most names/callsigns. Let me mess around in the tabulator thing for the editor, and maybe I can have it set or clear those values when you toggle between true/false on the "remapped" key.

You did better than me on finding that stuff on the EXTM3U format spec. It seems to me I also encountered the extra space at the beginning showing up in something else I was messing with early on in the locast2dvr days. But yeah, it's their issue and it should be on them to fix it (heck, it may be done even now, I probably have an old version of xTeVe anyway).

[wouterdebie]

Noted on your comments regarding implicit behavior. I'm fine with that. However, if someone is starting fresh on remapping, now they'll have to copy values from original to remap for most names/callsigns. Let me mess around in the tabulator thing for the editor, and maybe I can have it set or clear those values when you toggle between true/false on the "remapped" key.

I could set the remapped fields to the original values if the remap file doesn't specify a remap..

[wouterdebie]

I went ahead and set the remapped fields to the value of the original fields when they're not actively remapped. This means that you as a user don't have to fill in things if you only want to deactivate a channel or if you only want to change the channel number, but not the call sign. Let me know what you think.

[Croq360]

Okay, will take a look, but that sounds great!

Will your program be able to handle this scenario?

1. User sets "remapped" to true and makes a change to channel name or number or both.
2. They update their config file to use the new remap info they set up.
3. User changes their mind and decides they don't want to remap the channel any more, so they set "remapped" to false, but don't change the previous remappings they did. So you have "remapped" as false, but the original/remap channel number/name don't necessarily match up anymore.

[wouterdebie]

What happens is that the channel will not be remapped anymore. The remapped field is the gate for everything. If it's set to false the values that are in the json don't matter at all and are completely ignored.

[Croq360]

Okay, perfect. 👍

[Croq360]

Testing seems to be going okay so far with my remap file. Can watch live channels that have been remapped in Plex, Emby, and NextPVR. Recordings of shows are working in Plex. Will test the others later.

Working on my remap editor page, more to come there. Once that's in a state where it works a bit more seamlessly, I'll get a copy sent over to you to review and some documentation, and you can let me know what you think. One quick thing, since it uses another item from Github (tabulator.info), I'm not sure of the best way to handle that. Maybe I just provide in the instructions to get version 4.9 (since that's what I'm developing against), and put the remapEditor HTML file that we can provide here in the root folder for Tabulator, then open the remapEditor page. What do you think?

[wouterdebie]

Thanks for the extensive testing!

Once you have something nice, just send it over and I'll make things work :) If we want the user to have a seamless experience, we might want to provide a web interface regardless. Seems kind of silly to give them a web server, but when they want to modify things they would have to open an HTML file..

[Croq360]

Agreed. I should have something soon. Once it's ready, you and I could maybe get in a chat together and I can walk you through what it does, and how it all functions.

[Croq360]

Getting close - should have something for you to look at by Sunday.

[Croq360]

@wouterdebie - I just sent you a ZIP file with some documentation on what I created on Emby chatroom (Github's a bit limited on what I can attach). Let me know what you think (here or there), and we can get it incorporated in.

I'll be happy to create some user documentation once we get it all integrated.

[wouterdebie]

Awesome, thanks! I don't have much time this week to work on this, but hopefully I can look at it early next week. Apart from the UI, do you think the functionality is good to go?

[Croq360]

Yeah, honestly, I think the only thing it needs is a way for it to be integrated into locast2tuner so it can load in the current map/remap data. I tried doing a URL call from the page I created, but ran into a "cors" error when I tried to load up the map.json data from locast2tuner. I didn't really investigate it much further as you mentioned about integrating it into the web interface that locast2tuner has in place, so I just hard-coded in some remap data for testing with.

Everything else should work (or it did anyway with my testing as I was coding up the functionality).

I'll work on some preliminary documentation in the meantime. Should I use the remap_file branch to work on that, or pull from master?

[wouterdebie]

You mean a way to update the map data while running, right?

On Mon, Apr 26, 2021, 17:09 Croq360 @.***> wrote:

Yeah, honestly, I think the only thing it needs is a way for locast2tuner to load in the current map/remap data. Everything else should work (or it did anyway with my testing as I was coding up the functionality).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wouterdebie/locast2tuner/issues/36#issuecomment-827175991, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABKABTI2237OUDVW23WBB3TKXQABANCNFSM424DFGZA .

[Croq360]

I guess my impression on how things would work would be this:

1. User runs locast2tuner with no remapping (or I guess they could use the basic remapping).
2. User loads up webpage using locast2tuner local website
3. This loads up the page I created, which pulls in the current mapping information
4. User makes edits as they want
5. User clicks on Save JSON to save the updated mappings to a JSON file on their hard drive (remap.json)
6. User saves (or overwrites) remap.json to a location where they want to save it
7. User exits locast2tuner, then reruns it with "--remap=path/to/remap.json" to load up the new remapping

Now, if you think that locast2tuner could handle the remapping on its own, that' be even easier. We'd need to test out and see if you have to redo your Device/Guide settings or how you get Plex or Emby to recognize the changes you just made.

[wouterdebie]

Interesting... If we allow the user to edit stuff, having them save, upload and restart seems tedious and giving folks kind of a half-baked solution. So we could just add uploading the mapping back. The issues though are permissions to write to disk unauthenticated. And even if we add authentication (which we probably should), we would need HTTPS, user management and RBAC. Let me think about this one...

On Mon, Apr 26, 2021, 19:06 Croq360 @.***> wrote:

I guess my impression on how things would work would be this:

1. User runs locast2tuner with no remapping (or I guess they could use the basic remapping).
2. User loads up webpage using locast2tuner local website
3. This loads up the page I created, which pulls in the current mapping information
4. User makes edits as they want
5. User clicks on Save JSON to save the updated mappings to a JSON file on their hard drive (remap.json)
6. User saves (or overwrites) remap.json to a location where they want to save it
7. User exits locast2tuner, then reruns it with "--remap=path/to/remap.json" to load up the new remapping

Now, if you think that locast2tuner could handle the remapping on its own, that' be even easier. We'd need to test out and see if you have to redo your Device/Guide settings or how you get Plex or Emby to recognize the changes you just made.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wouterdebie/locast2tuner/issues/36#issuecomment-827216640, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABKABUXPS3XA6NCQXWDXEDTKX5WNANCNFSM424DFGZA .