CPVRChannelGroup - Persist: SQL constraint violation #172
Comments
|
Can you also provide a kodi debug log from when this happens? I'm facing the same problem from time to time, but I was not able to get a proper log file yet. |
|
Sure, no problem: http://gmeiner.xyz/kodi/kodi.debug.log |
|
Looking at the log file, I suspect that it has something to do with the channel groups, can you reproduce the database error with the "sync channel groups with backend" option in kodi off? (clear db after changing setting). Is it possible for you to run Jarvis if this wasn't a success, there were some database fixes there. |
|
@ksooo this is 100% reproducible, the problem is that in tvheadend a channel can be changed from tv to radio and the other way around. Kodi will not handle this and throw the sql error. Found some more recent reports from this db error and in all cases the channel to be added is a radio channel, so it never appears for tv channels. The problem according my debugging:
Steps to reproduce:
|
|
@Bastig Not needed to test Jarvis anymore as I encountered the same problem with it now ;-) |
|
@Glenn-1990 so is this purely a Kodi bug or do we have to fix something in the addon as well? If not please go ahead and close this ticket. |
|
Well pvr.hts will assign undefined channels (channels without a service) as tv channels, this will increase the chance to trigger this issue. It's possible to hide these undefined channels, as the user will not be able to watch them anyway... But the kodi issue is the main problem of this. |
|
Should we ignore channels without a service? IMO we shouldn't since it may be confusing. |
|
Maybe we should notify the user why tuning such a channel fails (display "no service assigned to this channel" or such), but that's not related to this issue. |
|
@Jalle19 What do you think of the kodi fix for this? |
|
Perhaps it would be enough to just log it? |
|
Any update on this? |
|
PR to fix this is still open: Seems that multiple users are suffering from this issue, but on the forums they just get the explanation that their db got corrupted... Try to google "ERROR: SQL: Abort due to constraint violation" almost every post with this error has the radio flag set, meaning that's it's most likely caused by the issue described above. |
|
Moin, yes, it's an Issue for me too. I am using vdr 2.2.0, vnsiserver 1.3.1, kodi 16.1 and vnsiclient 1.11.16. Have some Windows-10-Clients with kodi and now an odroid c2 with libreelec affected from this. I have to delete the TV29.db to bring back live tv after some time, again and again. I will try to deactivate the Channel Updates on the vdr server by setting: "UpdateChannels = 0" in the setup.conf and report back here, if this worked as workaround. Please bring the fix to krypton. Greetings Hoppel |
Since deactivation of channel updates by vdr I didn't had this issue again. As a workaround it's fine. |
Supersedes xbmc#8963 Fixes trac xbmc#16031 Closes kodi-pvr/pvr.hts#172 This fixes the problem without bumping the database version so it should be more possibly to get it merged for V17. Basically the code that persists channels has been made smarter. Instead of just blindly looking at the primary key stored in the object we query the database to check if a channel with the unique ID and client ID already exists. If it does, we update that channel, if not we create a new channel. There is more background information in the referenced PRs. This fix also has the added side-effect that it increases database performance. While a new SELECT statement has been added, we now do an UPDATE instead of a REPLACE INTO which prevents indexes from having to be re-calculated (REPLACE INTO basically does a DELETE followed by an INSERT). This also means we don't need to worry about the channel ID changing after the channel has been updated (which was a side effect of using REPLACE INTO).
Supersedes xbmc#8963 Fixes trac xbmc#16031 Closes kodi-pvr/pvr.hts#172 This fixes the problem without bumping the database version so it should be more possibly to get it merged for V17. Basically the code that persists channels has been made smarter. Instead of just blindly looking at the primary key stored in the object we query the database to check if a channel with the unique ID and client ID already exists. If it does, we update that channel, if not we create a new channel. There is more background information in the referenced PRs. This fix also has the added side-effect that it increases database performance. While a new SELECT statement has been added, we now do an UPDATE instead of a REPLACE INTO which prevents indexes from having to be re-calculated (REPLACE INTO basically does a DELETE followed by an INSERT). This also means we don't need to worry about the channel ID changing after the channel has been updated (which was a side effect of using REPLACE INTO).
Supersedes xbmc#8963 Fixes trac xbmc#16031 Closes kodi-pvr/pvr.hts#172 This fixes the problem without bumping the database version so it should be more possibly to get it merged for V17. Basically the code that persists channels has been made smarter. Instead of just blindly looking at the primary key stored in the object we query the database to check if a channel with the unique ID and client ID already exists. If it does, we update that channel, if not we create a new channel. There is more background information in the referenced PRs. This fix also has the added side-effect that it increases database performance. While a new SELECT statement has been added, we now do an UPDATE instead of a REPLACE INTO which prevents indexes from having to be re-calculated (REPLACE INTO basically does a DELETE followed by an INSERT). This also means we don't need to worry about the channel ID changing after the channel has been updated (which was a side effect of using REPLACE INTO).
Supersedes xbmc#8963 Fixes trac xbmc#16031 Closes kodi-pvr/pvr.hts#172 This fixes the problem without bumping the database version so it should be more possibly to get it merged for V17. Basically the code that persists channels has been made smarter. Instead of just blindly looking at the primary key stored in the object we query the database to check if a channel with the unique ID and client ID already exists. If it does, we update that channel, if not we create a new channel. There is more background information in the referenced PRs. This fix also has the added side-effect that it increases database performance. While a new SELECT statement has been added, we now do an UPDATE instead of a REPLACE INTO which prevents indexes from having to be re-calculated (REPLACE INTO basically does a DELETE followed by an INSERT). This also means we don't need to worry about the channel ID changing after the channel has been updated (which was a side effect of using REPLACE INTO).
Supersedes xbmc#8963 Fixes trac xbmc#16031 Closes kodi-pvr/pvr.hts#172 This fixes the problem without bumping the database version so it should be more possibly to get it merged for V17. Basically the code that persists channels has been made smarter. Instead of just blindly looking at the primary key stored in the object we query the database to check if a channel with the unique ID and client ID already exists. If it does, we update that channel, if not we create a new channel. There is more background information in the referenced PRs. This fix also has the added side-effect that it increases database performance. While a new SELECT statement has been added, we now do an UPDATE instead of a REPLACE INTO which prevents indexes from having to be re-calculated (REPLACE INTO basically does a DELETE followed by an INSERT). This also means we don't need to worry about the channel ID changing after the channel has been updated (which was a side effect of using REPLACE INTO).
Supersedes xbmc#8963 Fixes trac xbmc#16031 Closes kodi-pvr/pvr.hts#172 This fixes the problem without bumping the database version so it should be more possibly to get it merged for V17. Basically the code that persists channels has been made smarter. Instead of just blindly looking at the primary key stored in the object we query the database to check if a channel with the unique ID and client ID already exists. If it does, we update that channel, if not we create a new channel. There is more background information in the referenced PRs. This fix also has the added side-effect that it increases database performance. While a new SELECT statement has been added, we now do an UPDATE instead of a REPLACE INTO which prevents indexes from having to be re-calculated (REPLACE INTO basically does a DELETE followed by an INSERT). This also means we don't need to worry about the channel ID changing after the channel has been updated (which was a side effect of using REPLACE INTO).
Loading the hts plugin will frequently on reboot and the screen gets stuck in 'Starting PVR manager'.
I'm using TVHeadend with two satellite networks (Astra + Hotbird) so there are plenty of services and channels mapped. It seems the issue occurs when a video PID is missing and a channel that was classified 'tv' is changed to 'radio' or vice versa. This happens every few hours so I have to clear the TV DB on every reboot.
In this such a case the logs would give me an error like this:
At the same time TV29.db already contains the following entry in table channels:
The records only differ in bIsRadio (insert statement wants to set it 1, exists as 0) and idEpg (insert: -1, exists: 1711). The error gets thrown because the records would share the same values for iUniqueId and iClientId (unique index).
Environment:
ArchLinux 4.3.3-2 x86_64
Kodi 15.2
kodi-addon-pvr-hts 2.1.18-1 (built from Isengard branch)
Note: I'm not sure if it's a bug in the addon or rather in the Kodi PVR manager but I understand that existing channels should have the m_iChannelId field populated in order to have the PVR manager call 'REPLACE INTO' rather than 'INSERT INTO'.
The text was updated successfully, but these errors were encountered: