[mythtv-users] mythmusic - problems with ripping

[Vincent McIntyre]

Hi again

more fun.

First I had to re-tell mythmusic where to look for music:
/var/lib/mythtv/music

$ ls -ld /var/lib/mythtv/music
drwxrwsr-x 274 mythtv mythtv 20480 Jun  2  2018 /var/lib/mythtv/music/

Then I tried to get it to rip a disc that was showing as missing tracks
(see previous post to the list about 'scan for new music').

It failed with this error on screen:

  The encoder failed to create the file.
  Do you have write permissions for the music directory?

The frontend log had
 E CDRipper cdrip.cpp:366 (run) MythMusic: No encoder, failing

As above the permissions should be ok -
the backend runs as 'mythtv',
the frontend runs as 'frontend',
both are in the 'mythtv' group.
Which user is supposed to be doing the writing ?

The permissions on the artist subdir also matters,
I verified that was correct also.

After mucking about a bit I discovered the issue seemed to be that
the tracks were still in the database and mythripper did not want to
overwrite them, which is fair enough.

So in the rip screen I highlighted a track and asked mythripper to
delete it. It did not complain in the UI but in the frontend log
it complained that it could not find the file:

  N CoreContext cdrip.cpp:969 (deleteExistingTrack) Ripper::deleteExistingTrack() Could not delete myth://Music@/Suzuki_Method_International,_Seizo_Azuma/Suzuki_Piano_School,_Volume_3,_New_International_Edition/01-Sonatina_in_C_major,_op._36,_no._1__Allegro.flac

This seems like a bug to me - if it can't find the file, it should
still be able to remove the database record.

So I faked up some files that it could delete and thus cleared the
database entries.

I tried the rip again. Next error (isn't this fun?):

  E CDRipper mythdbcon.cpp:690 (exec) Original query failed, but resend with empty strings in place of NULL strings worked. #012DB Error (MSqlQuery):#012Query was:#012INSERT INTO music_songs ( directory_id, artist_id, album_id,    name,         genre_id, year,      track,       length,       filename, rating,    format,      date_entered, date_modified, numplays,  track_count, disc_number,  disc_count, size,      hostname) VALUES (  ?,  ?,   ?,      ?,       ?, ?,     ?,   ?,      ?, ?,   ?,     ?,    ?, ?,?, ?, ?, ?,     ? );#012Bindings were:#012:ALBUM=366, :ARTIST=383, :DATE_ADD=2019-02-02T02:41:19Z,#012:DATE_MOD=2019-02-02T02:41:19Z, :DIRECTORY=633, :DISC_COUNT=0, :DISC_NUMBER=0,#012:FILENAME="01-Sonatina_in_C_major,_op._36,_no._1__Allegro.flac", :FORMAT="",#012:GENRE=4, :HOSTNAME=NULL, :LENGTH=97960, :PLAYCOUNT=0, :RATING=0, :SIZE=0,#012:TITLE="Sonatina in C major, op. 36, no. 1: Allegro", :TRACKCOUNT=0, :TRACKNUM=1,#012:YEAR=2008#012Driver error was [2/1048]:#012QMYSQL3: Unable to execute statement#012Database error was:#012Column 'hostname' cannot be null
  E CDRipper remotefile.cpp:250 (openSocket) RemoteFile::openSocket(file data socket): Failed to open socket, error was filetransfer_directory_not_found
  E CDRipper remotefile.cpp:643 (CopyFile) RemoteFile::CopyFile: Failed to open file (myth://Music@/Seizo_Azuma/Suzuki_Piano_School,_Volume_3,_New_International_Edition/01-Sonatina_in_C_major,_op._36,_no._1__Allegro.flac) for writing.

This was repeated the same for every track.
Sadly, the ripper thought that it had succeeded.
I haven't checked if the database was updated.

Now, I have never messed with the database internally.
The system is a combined fe/be that only talks to localhost.
I did toy with setting the hostname at one time but never went ahead.

So it would appear that because I have not set the hostname,
or because it somehow got set to null (not by me) I'm stuck.
Is this a new bug in the ripping code?

Vince