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
Support
Watch / Listen Media
Television (MyTV frontend and TV-Server)
Recording Failed To Start
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="mm1352000" data-source="post: 1107003" data-attributes="member: 82144"><p>Hello again</p><p></p><p></p><p>I'm pretty sure that when you deselect "store data..." the EPG grabber will store for both radio and TV channels. In other words: no need to configure separate radio grabbing.</p><p></p><p></p><p>This all makes sense.</p><p>The channels that have no data are the ones that aren't tunable. Like you say, those channels probably experienced more significant changes as part of the "retune event". Maybe they were moved to a different mux, and maybe their identifiers (service ID etc.) were changed. If they were moved to a different mux then I'd expect tuning would fail but EPG might continue to be shown. If their identifiers were changed then tuning will fail and EPG won't be picked up even though it is available in the broadcast. The EPG grabber would see the data but wouldn't know which channels to link it to.</p><p></p><p>The only way to fix the "tunability" and EPG for these channels is to fix their tuning details - frequency etc. as well as identifiers. It is easiest to do this by scanning, but it can also be done manually if you can get access to the correct details from another source (such as your Humax STB).</p><p></p><p></p><p>Assuming the channel identifiers have changed for the broken channels and not changed for the working channels, the effect would be:</p><ol> <li data-xf-list-type="ol">Scanning does not directly touch schedules. Any effects on schedules described below are the result of effects on channels.<br /> </li> <li data-xf-list-type="ol">The existing channels that work should effectively be completely unchanged. Unchanged in that they should continue to be tunable, and the associated schedules should continue to record. Unchanged even to the degree that the saved name and logical channel number won't be touched even if the broadcast name and/or LCN have changed. TV Server does not update names or LCNs as it currently can't tell the difference between standard and user-modified names/LCNs. <br /> </li> <li data-xf-list-type="ol">The effect for existing channels that don't work depends on the scan settings and the reason the channels don't work.<ol> <li data-xf-list-type="ol">Channels that have changed identifiers would continue to exist in their current untunable state with no EPG data. Any schedules associated with these channels would continue to fail to record. TV Server <strong>never </strong>automatically deletes channels.<br /> </li> <li data-xf-list-type="ol">For channels that have moved to a different mux but kept the same identifiers:<ul> <li data-xf-list-type="ul">If you scan with "channel movement" detection enabled then the rescan should fix such channels. Fix in that they should become tunable again and the EPG show show again. Associated schedules should start working again given that the channels are tunable.</li> <li data-xf-list-type="ul">If you scan with "channel movement" detection disabled then the outcome is expected to be the same as if the identifiers changed. In other words: channels remain in the database along with schedules in broken state, and no EPG data.</li> </ul></li> </ol></li> <li data-xf-list-type="ol">Replacements for channels whose identifiers have changed should be created along with any genuinely new channels that have been added to the broadcast platform. If the EPG grabber is configured appropriately, all of these channels - replacement and new - should get EPG data automatically. The existing "record on any channel" schedules will apply to the new channels automatically. The other existing schedules that are associated with specific channels will <strong>not</strong> be automatically transferred to replacement channels. There is no association between a replacement and its previous incarnation to enable this. From TV Server's perspective replacement channels look just like any other new channel.</li> </ol><p>In short, the intention is that a rescan should do as much good as possible with zero harm.</p><p></p><p>Beyond rescanning you can do in-place fixing of broken channels:</p><ol> <li data-xf-list-type="ol"><a href="http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/141_Configuration/TV-Server_Configuration/03_TV_Channels/1_Combinations" target="_blank">Combine </a>the existing channels with their replacements.</li> <li data-xf-list-type="ol">Edit the combined channels and delete the non-working tuning details.</li> </ol><p>...OR...</p><ol> <li data-xf-list-type="ol">Manually copy the working tuning details from the replacement channels back to the existing channels.</li> </ol><p>Both of these would avoid having to recreate schedules, reorganise groups, and re-map tuners.</p><p></p><p>Regards,</p><p>mm</p></blockquote><p></p>
[QUOTE="mm1352000, post: 1107003, member: 82144"] Hello again I'm pretty sure that when you deselect "store data..." the EPG grabber will store for both radio and TV channels. In other words: no need to configure separate radio grabbing. This all makes sense. The channels that have no data are the ones that aren't tunable. Like you say, those channels probably experienced more significant changes as part of the "retune event". Maybe they were moved to a different mux, and maybe their identifiers (service ID etc.) were changed. If they were moved to a different mux then I'd expect tuning would fail but EPG might continue to be shown. If their identifiers were changed then tuning will fail and EPG won't be picked up even though it is available in the broadcast. The EPG grabber would see the data but wouldn't know which channels to link it to. The only way to fix the "tunability" and EPG for these channels is to fix their tuning details - frequency etc. as well as identifiers. It is easiest to do this by scanning, but it can also be done manually if you can get access to the correct details from another source (such as your Humax STB). Assuming the channel identifiers have changed for the broken channels and not changed for the working channels, the effect would be: [LIST=1] [*]Scanning does not directly touch schedules. Any effects on schedules described below are the result of effects on channels. [*]The existing channels that work should effectively be completely unchanged. Unchanged in that they should continue to be tunable, and the associated schedules should continue to record. Unchanged even to the degree that the saved name and logical channel number won't be touched even if the broadcast name and/or LCN have changed. TV Server does not update names or LCNs as it currently can't tell the difference between standard and user-modified names/LCNs. [*]The effect for existing channels that don't work depends on the scan settings and the reason the channels don't work. [LIST=1] [*]Channels that have changed identifiers would continue to exist in their current untunable state with no EPG data. Any schedules associated with these channels would continue to fail to record. TV Server [B]never [/B]automatically deletes channels. [*]For channels that have moved to a different mux but kept the same identifiers: [LIST] [*]If you scan with "channel movement" detection enabled then the rescan should fix such channels. Fix in that they should become tunable again and the EPG show show again. Associated schedules should start working again given that the channels are tunable. [*]If you scan with "channel movement" detection disabled then the outcome is expected to be the same as if the identifiers changed. In other words: channels remain in the database along with schedules in broken state, and no EPG data. [/LIST] [/LIST] [*]Replacements for channels whose identifiers have changed should be created along with any genuinely new channels that have been added to the broadcast platform. If the EPG grabber is configured appropriately, all of these channels - replacement and new - should get EPG data automatically. The existing "record on any channel" schedules will apply to the new channels automatically. The other existing schedules that are associated with specific channels will [B]not[/B] be automatically transferred to replacement channels. There is no association between a replacement and its previous incarnation to enable this. From TV Server's perspective replacement channels look just like any other new channel. [/LIST] In short, the intention is that a rescan should do as much good as possible with zero harm. Beyond rescanning you can do in-place fixing of broken channels: [LIST=1] [*][URL='http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/141_Configuration/TV-Server_Configuration/03_TV_Channels/1_Combinations']Combine [/URL]the existing channels with their replacements. [*]Edit the combined channels and delete the non-working tuning details. [/LIST] ...OR... [LIST=1] [*]Manually copy the working tuning details from the replacement channels back to the existing channels. [/LIST] Both of these would avoid having to recreate schedules, reorganise groups, and re-map tuners. Regards, mm [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Watch / Listen Media
Television (MyTV frontend and TV-Server)
Recording Failed To Start
Contact us
RSS
Top
Bottom
