[Claudio.Sjo]

Now filed as bug as well
https://savannah.gnu.org/bugs/index.php?44355

There's something new I'd wish to add: CD Ripping works pretty well with the Confluence Skin,
even though it stops working when RPi is loaded, for instance when copying a file using scp from a Linux workstation.

If another skin is chosen, i.e. Transparency, the Rip stops working randomly, and by checking the log the fault is not in CDDAFile::Read
Shall I file another bug?

[Milhouse]

It does seem rather odd that a different skin would cause a different problem - if you can narrow down the issue then sure, file another bug.

[un1versal]

I think the crashes are being caused by libcdio 0.92, Ubuntu is stuck on using 0.83 and there's no crashes there. So the cdda patch https://github.com/xbmc/xbmc/pull/6461 has no effect on my system either way.

I cant test that theory though because i dont have a PI or use OE

Ive asked for forum.kodi.tv/showthread.php?tid=227317 to be merged with this one as theire clearly the same issue where failed ripping is concerned.

Now the ripping failures are I believe Linux specifc, Ive experienced this BUG since December and Montellese as made claims that in Windows the audio encoders all work.

[Blindrabbit]

Seems like it is not Linux specific;

I've got the same issue with Kodi 15.1 running on windows 7. I am using Lame MP3 @ 128kbit. Ripping stops after track 2 without notice.

The only link I can see is that the DVD Drive is coupled via USB (Lenovo IDEACentre Standard setup)

[Claudio.Sjo]

This confirms that the problem is Kodi's buffer mechanism.
Unfortunately I didn't manage to get the right people involved, Kodi's cache buffer mechanism is simply impossible to understand simply reading the source code.

[popcornmix]

As this doesn't seem to be Pi specific, I've moved it to the OS independent forum where perhaps some more devs will see it.

[Blindrabbit]

Interestingly , while ripping failed with constant bitrate, it worked out with variable bitrate, although higher rates were used. maybe this sheds some more light on it...

[DaVu]

IIRC this issue exists since december last year and it's not getting any further. I would spend a beer (or 2) if this will ever be solved. But unfortunately I doubt it.

No offense to anyone!

[Claudio.Sjo]

Is it possible at least to have a description about the way FileCache is expected to work?
I think the same problem applies to other files accessed through timeout-prone media such as Samba shares.

My 2 beers are waiting...

[PJF16]

I have the same problem. Mine Pi stops after 4 tracks. Any help? :/

Code:

16:01:33 T:1752429488    INFO: CFileCache::Process - Hit eof.
16:01:43 T:1465656240   DEBUG: Thread JobWorker 1465656240 terminating (autodelete)
16:01:48 T:1532851120   DEBUG: ffmpeg[5B5D73B0]: [aac] 1 frames left in the queue on closing
16:01:48 T:1752429488   DEBUG: Thread FileCache 1752429488 terminating
16:01:48 T:1532851120    INFO: Finished ripping cdda://local/03.cdda
16:01:48 T:1532851120    INFO: Start ripping track cdda://local/04.cdda to /media/pi/wddexternal/Musik/Raphael Sas/Raphael Sas - Nackerte Lieder/04. $
16:01:48 T:1752429488  NOTICE: Thread JobWorker start, auto delete: true
16:01:48 T:1532851120   DEBUG: CFileCache::Open - opening <04.cdda> using cache
16:01:48 T:1465656240  NOTICE: Thread FileCache start, auto delete: false
16:01:48 T:1532851120   DEBUG: ffmpeg[5B5D73B0]: [ipod] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.ti$
16:01:48 T:1532851120   DEBUG: CEncoderFFmpeg::Init - Successfully initialized with muxer iPod H.264 MP4 (MPEG-4 Part 14) and codec AAC (Advanced Aud$
16:01:48 T:1946337280   DEBUG: ------ Window Init (DialogExtendedProgressBar.xml) ------
16:02:06 T:1465656240   DEBUG: Thread FileCache 1465656240 terminating
16:02:18 T:1752429488   DEBUG: Thread JobWorker 1752429488 terminating (autodelete)
16:02:24 T:1532851120   DEBUG: ffmpeg[5B5D73B0]: [aac] 1 frames left in the queue on closing
16:02:24 T:1532851120   ERROR: CDDARipper: Error ripping cdda://local/04.cdda
16:02:24 T:1946337280   DEBUG: ------ Window Deinit (DialogExtendedProgressBar.xml) ------

[un1versal]

Still a valid bug and still unresolved.

hurrah for binary addons.

[dabidovich]

For me (currently using OSMC in raspberry pi and USB DVD-ROM) it's definitely speed problem, as Claudio.Sjo (Thanks!) posted before: drive is faster than pi software

While patch arrives, I have found a working workaround:

Just slow down your cd-rom/dvd-rom drive

x4 speed did the trick for me (which anyhow is the minimum speed for my drive) and lame mp3 rip worked perfectly.

You can do this speed change once or make it permanent, which is quite useful to avoid noise on playback.

I installed eject and util-linux

Code:

sudo apt-get install util-linux
sudo apt-get install eject

Using this command you can adjust speed (E# means x# speed, in this case E4 means x4 speed, slow enough for ripping properly)

Code:

hdparm -E4 /dev/sr0/

Where sr0 is device name. Use

Code:

lsblk

to list your device, it may be something like cd-rom or DVD instead of sr0 in the example above

Code:

hdparm -E4 /dev/cdrom/
hdparm -E4 /dev/dvd/

To make it permanent I think you may add udev-rule. If someone's interested I can post howto.