home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
Improvement Suggestions
Scanning for new/updated channels results in a mess
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="doveman" data-source="post: 703746" data-attributes="member: 67412"><p>I imagine it's also bad practice to ignore very real and known possibilites (even if they are exceptional) that will cause the program to malfunction (in the sense that the user will experience problems). I'm not suggesting that the code should be written to cope with these situations in a way that would cause problems the rest of the time and perhaps there is no way to code it so that this doesn't happen. I'll see if I can suggest a workable way to handle this, once I further understand how things currently work.</p><p></p><p></p><p></p><p>But from what I understand, the three id's are now also used for the unique id as well, so that they're stored in two separate locations. Maybe table is the wrong word, in which case please tell me which word is more accurate so that we understand each other.</p><p></p><p></p><p></p><p>I don't see how the unique id can be "nothing to do with what is found on the network" if it consists of the three identifiers and the channel name, which are all pulled from the network. If I understand correctly, each channel is assigned a unique ID, consisting of the three identifiers (ie the tuning details) and the channel name, and this unique ID also links to a separate location which also stores the three ids (the tuning details). Is this correct?</p><p></p><p></p><p></p><p>It seems stupid for a broadcaster to give several channels the same name, simply because it looks strange and confusing to have several channels with the same name in the EPG. And imagine the conversation in the office "Did you see that programme on ChannelHistory last night", "Oh, which one, there's four" <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" /></p><p></p><p>Perhaps, when scanning, if MP picks up a channel with the same name but different tuningdetails as a channel already picked up and entered in the database, it could assign a suffix to the name to store as the unique ID. So that you'd have ChannelHistory-a, ChannelHistory-b, etc.</p><p></p><p>As for dealing with channel names changes, perhaps if the channel name is stored with the scheduled recordings data, then after a re-scan MP could look to see if there were any scheduled recordings on channel names that no longer existed. Then it could either scan the programme names in the EPG (once updated) to see if it could find the scheduled recordings, thus automatically identifying the new channel name, or it could just notify the user that the channel name no longer existed and ask them to manually locate the new channel name and assign it to those recordings (or tell MP that the channel has been taken off-air and to discard those scheduled recordings).</p></blockquote><p></p>
[QUOTE="doveman, post: 703746, member: 67412"] I imagine it's also bad practice to ignore very real and known possibilites (even if they are exceptional) that will cause the program to malfunction (in the sense that the user will experience problems). I'm not suggesting that the code should be written to cope with these situations in a way that would cause problems the rest of the time and perhaps there is no way to code it so that this doesn't happen. I'll see if I can suggest a workable way to handle this, once I further understand how things currently work. But from what I understand, the three id's are now also used for the unique id as well, so that they're stored in two separate locations. Maybe table is the wrong word, in which case please tell me which word is more accurate so that we understand each other. I don't see how the unique id can be "nothing to do with what is found on the network" if it consists of the three identifiers and the channel name, which are all pulled from the network. If I understand correctly, each channel is assigned a unique ID, consisting of the three identifiers (ie the tuning details) and the channel name, and this unique ID also links to a separate location which also stores the three ids (the tuning details). Is this correct? It seems stupid for a broadcaster to give several channels the same name, simply because it looks strange and confusing to have several channels with the same name in the EPG. And imagine the conversation in the office "Did you see that programme on ChannelHistory last night", "Oh, which one, there's four" :D Perhaps, when scanning, if MP picks up a channel with the same name but different tuningdetails as a channel already picked up and entered in the database, it could assign a suffix to the name to store as the unique ID. So that you'd have ChannelHistory-a, ChannelHistory-b, etc. As for dealing with channel names changes, perhaps if the channel name is stored with the scheduled recordings data, then after a re-scan MP could look to see if there were any scheduled recordings on channel names that no longer existed. Then it could either scan the programme names in the EPG (once updated) to see if it could find the scheduled recordings, thus automatically identifying the new channel name, or it could just notify the user that the channel name no longer existed and ask them to manually locate the new channel name and assign it to those recordings (or tell MP that the channel has been taken off-air and to discard those scheduled recordings). [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
Improvement Suggestions
Scanning for new/updated channels results in a mess
Contact us
RSS
Top
Bottom