Feature #2539
openImprove remapping of already mapped channels
0%
Description
Hi,
When mapping the xmltv channel ids to the channels from the channels.conf by using the OSD of the xmltv plugin, the channels of the channels.conf that are already mapped have a different color and are skipped.
After an update of the channels from the broadcaster, some channels have disappeared, new channels have appeared and others have changed their frequency or name. This results in channels that are wrongly mapped.
For example, let's assume that the channel "das Erste" has moved and the channel "ZDF" is now available on the frequency from "das Erste". This results in ZDF being wrongly mapped to daserste.de .
If the user now wants to map ZDF to zdf.de, it does not work, because ZDF gets skipped, as it is already mapped to daserste.de. The user has to first unmap ZDF from daserste.de.
And now I come to the reason for the feature request:
After a channel update from the broadcaster, the user does not know how the channels have changed. So, in the example above, he does not know that ZDF is mapped to daserste; when trying to map ZDF he is not able to select it, as it is already mapped.
Thus, could you remove the restriction of the mapped channels not being selectable? Can't you simply allow the user to also select already mapped channels so that their mapping can be updated?
Thanks in advance for taking the problem into account.
Updated by Ludi over 6 years ago
To solve the problem, the user has to go into the edition mode of each xmltv channel ID in order to check whether there aren't any wrongly mapped channels. (Or at least in order to find the wrongly mapped channel.) This is quite time consuming, as the channel mapping is not visible at once, if the mapping is using the create mode instead of the merge mode. In this case, a fix for #1806 would ease the problem.
Updated by Ludi over 6 years ago
Another reason for reworking the mapping:
Let's assume some channels were mapped to daserste.de (to keep the example from the first message). The channels belonging to daserste.de disappear; the grabber gets updated and the daserste.de entry gets removed from the grabber.
However, the daserste.de entry remains in the setup.conf file and the zdf channel that took the place of a channel of daserste.de is now mapped to daserste.de that only exists in the setup.conf file.
The user has to edit the setup.conf file manually (with a stopped vdr) to delete the daserste.de entry in order to make the zdf channel available for a fresh mapping, as the zdf channel is not anymore accessible by OSD because the daserste.de entry is not anymore in the grabber that has been updated.