[mythtv-users] Mirobridge failing to update mythtv db entries

[rdvAndroid@gmail.com]

On 14-06-10 08:54 AM, Daniel Frey wrote:
> This only started recently, but after running an update on June 9th, 
> 2014.
>
> Mythbuntu 12.04.4 LTS
> MythTV Version : v0.27.1-14-g2720f45
> MythTV Branch : fixes/0.27
> Network Protocol : 77
> Library API : 0.27.20140520-1
>
> Here is the exception. Â The whole log is attached.
>
> Traceback (most recent call last):
> Â  File 
> "/usr/share/doc/mythtv-backend/contrib/imports/mirobridge/mirobridge.py", 
> line 2800, in <module>
> Â  Â  main()
> Â  File 
> "/usr/share/doc/mythtv-backend/contrib/imports/mirobridge/mirobridge.py", 
> line 2766, in main
> Â  Â  if not updateMythRecorded(unwatched):
> Â  File 
> "/usr/share/doc/mythtv-backend/contrib/imports/mirobridge/mirobridge.py", 
> line 1828, in updateMythRecorded
> Â  Â  records = createRecordedRecords(item)
> Â  File 
> "/usr/share/doc/mythtv-backend/contrib/imports/mirobridge/mirobridge.py", 
> line 1414, in createRecordedRecords
> Â  Â  graphics = 
> metadata.getMetadata(sanitiseFileName(item[u'channelTitle']))
> Â  File 
> "/usr/share/doc/mythtv-backend/contrib/imports/mirobridge/mirobridge/metadata.py", 
> line 172, in getMetadata
> Â  Â  record = self.Record().create(self.makeRecordRule)
> Â  File "/usr/lib/python2.7/dist-packages/MythTV/dataheap.py", line 
> 161, in __init__
> Â  Â  DBDataWrite.__init__(self, data, db)
> Â  File "/usr/lib/python2.7/dist-packages/MythTV/database.py", line 
> 317, in __init__
> Â  Â  DBData.__init__(self, data, db)
> Â  File "/usr/lib/python2.7/dist-packages/MythTV/database.py", line 
> 169, in __init__
> Â  Â  self._setDefs()
> Â  File "/usr/lib/python2.7/dist-packages/MythTV/database.py", line 
> 305, in _setDefs
> Â  Â  DBData._setDefs(self)
> Â  File "/usr/lib/python2.7/dist-packages/MythTV/database.py", line 
> 160, in _setDefs
> Â  Â  self.__class__._setClassDefs(self._db)
> Â  File "/usr/lib/python2.7/dist-packages/MythTV/dataheap.py", line 
> 118, in _setClassDefs
> Â  Â  defaults = cls._template('Default', db=db)
> Â  File "/usr/lib/python2.7/dist-packages/MythTV/dataheap.py", line 
> 128, in _template
> Â  Â  tmp = cls._fromQuery("WHERE title=?", (name + " (Template)",))\
>
>
> -- 
> My Google Profile <http://www.google.com/profiles/dmfrey>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
Daniel,
     I'm running a close configuration to yourself with two exceptions, 
Ubuntu 12.10 and Miro 6.0 but the latest compile of 0.27. I doubt that 
these variations are the issue, The abort is occuring in one of the 
MythTV python bindings that MiroBridge calls to create a RecordRule that 
so you can get artwork for the specific Miro Channel. That Miro Channel 
has graphics on thetvdb.org, Did you add a new Miro Channel lately? Of 
course an old channel could have new artwork on thetvdb.org

 From the BE you run Mir*obridge, *from the command line run then cut 
and replace the output into a reply email. Lets eliminate the bindings 
first.
 > mythpython --version

Example output:
MythTV Python Bindings
   local versions
     bindings version:         0.27.-1.0
     ttvdb version:            1.2.1
     tmdb version:             v0.7.0
   external versions
     lxml version:             2.3.5
     MySQLdb version:          1.2.3.final.0
   protocol versions
     backend:                  77
     schema:                   1317
     music schema:             1018
     netvision schema:         1007

This sound like an issue with RecordedRule (new artwork) that I helped a 
user with a number-to-many months ago. It was not a MiroBridge bug (no 
code changes required). I'm getting old so I can't remember how the user 
and I resolved the abort. It was on the MythTV user mailing list so a 
search may find that thread and how the problem was resolved. that's 
probably ftaser than going through the analysis process again.

Doug