[papua]

Hi folks,

somthing might be wrong here. I've got quite a large audio-database in xbmc, but that didn't matter in Frodo. After the update to Gotham, playing audio is a stuggle.

I did a new, fresh install, though. Generated a new database on a windows machine, transfered it to the Pi. Everything is there, can be found and accessed. But when I choose an album to play (i.e. with Yatse), it take ages until the playback starts. Five minutes in the last test.

At first I thought the nfs was sleeping and the wake up failed (which happened before). But all is ok in this matter. It just keep waiting.

A short logging brought up nothing special. The "Pausing Time" is filled with 100% CPU. So there is somethine done. In that time, a lot of these lines come up:
16:19:06 T:3037188096 DEBUG: CAnnouncementManager - Announcement: OnAdd from xbmc
16:19:06 T:3037188096 DEBUG: GOT ANNOUNCEMENT, type: 2, from xbmc, message OnAdd
16:19:20 T:3037188096 DEBUG: CAnnouncementManager - Announcement: OnAdd from xbmc
16:19:20 T:3037188096 DEBUG: GOT ANNOUNCEMENT, type: 2, from xbmc, message OnAdd

A new test showed that the full cpu is only after 30 seconds or so. The screen is already getting darker, still 100% nothing to hear. user.log shows a lot of smb calls to cover arts for ALL albums of that band. The whole time of waiting is filled with this actions.

xbmc.log indicates that yatse is requesting the album art. But why is the pi stalled doing that? When playback is about to start, the OnAdd-Events come again. The count of that is roughly the number of tracks. But over minute to fill a playback list with an album? What is slowing down the stuff?

Any ideas?

PS: log here: http://xbmclogs.com/show.php?id=213632. Action starts an 20:35 time

[Bosse_B]

I have a less demanding setup:
- RASPBMC is isntalled on a Raspberry Pi type B from 2012, so it has the small RAM chip (256 Mb)
- Started out in January with RASPBMC, at the time the December 2013 release (Frodo)
- Automatically updated itself to Gotham a few weeks ago
- Only about a hundred video files (mp4) residing on a NAS unit, mostly children's programs like Pingu etc
- Accessed as files, nothing is added to any library
- Synology NAS is accessed using SAMBA over wired network

But I am also experiencing LONG delays before a video starts playing, it is as if XBMC did not see the YATSE remote command.
But after a long wait the display dims a bit and then a LOADING message appears at the bottom and after yet a bit of wait the video starts playing.

It was never this bad on the earlier Frodo release even though sometimes there was some waiting to start viewing a video.
But after the update to Gotham it is really much slower.

Seems to be a common feature of Gotham.

[popcornmix]

- Only about a hundred video files (mp4) residing on a NAS unit, mostly children's programs like Pingu etc

Are all files in a single directory? This adds to load time.
Put each video in a separate directory (along with associated files like artwork and sub). One the library is scanned it will look just the same to you.
But playback will be much quicker.

When a video is played, every file in the same directory is checked to see if it is an associated file (subtitle, edl, etc).
With hundreds or thousands of files in a single directory this gets slow.

[Bosse_B]

I think that the biggest directory holds some 50 Pingu videos, each 5 minutes long.
All other folders (5-8 of them) hold max 12 each.
I have no other files to bother with, why should I use any artwork in addition to the videos?

[Milhouse]

Any ideas?

Sounds like playlist processing, whenever you play a song all the songs in the same folder will be added as a playlist - this involves sending a notification for each song as it is added to the playlist. Hundreds or even thousands of songs in the folder means hundreds or thousands of notifications. You can see the notifications by running the script in my signature using the "monitor" option.

[JoyrexJ9]

Same problem here. I have a large-ish music library of 1,100 albums (in standard folder structure /artist/album/track-name.mp3)
Never had any problems with Frodo version of Raspbmc, now the lag starting a new track is HORRENDOUS. It can take 60 seconds or more before a new track starts when that track is on a new or different album. Track skips within an album are fast as normal (however still slower than with Frodo)

Not sure it's a folder size issue, on average the file count in a folder will be 11-12 for an album (obviously some will be more)

This needs seriously looking into

[Milhouse]

@JoyrexJ9 - confirm how many songs are being added to your playlist using the method in post #5, everything else is guesswork.

[JoyrexJ9]

Logs here
http://pastebin.com/vj2ebt5e

What is happening is Yatse is adding each of the tracks in the album to the current playlist, each track addition takes 2-3 seconds. XBMC is being incredibly slow in doing this

See line 277 in the log when I hit play on the first track on Queen's 'A Night At The Opera' then there are lines
"GOT ANNOUNCEMENT, type: 2, from xbmc, message OnAdd" about 2 secs apart for all 12 tracks, as it fills the playlist. Only when all tracks are added does it start playing.

Again line 367 I start playing an album (by The Caretaker) then 14 x GOT ANNOUNCEMENT logs (the album has 14 tracks), before the album starts around line 623.

If you want video proof, you can see it happening if you watch the current playlist view in XBMC.
https://www.youtube.com/watch?v=md32dcKNV3U

I'm not sure who is entirely at fault, Yatse or XBMC. But I think it's XBMC

[popcornmix]

I'm not sure who is entirely at fault, Yatse or XBMC. But I think it's XBMC

What happens if you don't play music with Yatse, but use keyboard?

[Tolriq]

For information in this case Yatse does send a single JSON request to Xbmc.

It's a batched one containing a playlist.clear followed by playlist.add using songid references then player.open.

But all in a single query, so all the processing time is on Xbmc side. JSON return is fast.

[JoyrexJ9]

I'm not sure who is entirely at fault, Yatse or XBMC. But I think it's XBMC

What happens if you don't play music with Yatse, but use keyboard?

I tried two ways of playing an album using the main XBMC UI:

• Playing an album by highlighting the album name & bringing up the content menu, and choosing 'Play'
  This is slow, UI hangs for ~10-15 seconds or so before music starts
  
• Playing an album by going into track list and hitting select on first track
  Much faster, takes 4 seconds before music starts, no UI hang
  

However, it was never this slow generally on Frodo

[popcornmix]

I don't know this part of the code well.
If it was faster on Frodo, then it suggests either Frodo didn't add tracks to playlist, or it did, but adding tracks to playlist used to be quicker.

It would be interesting to determine which of these two cases is true (presumably capturing the same log on Frodo should provide some information).

It would also be useful to track down the commit between Frodo and Gotham that made it slower and decide if that is doing something unnecessary.

[Milhouse]

I'm not sure who is entirely at fault, Yatse or XBMC. But I think it's XBMC

What happens if you don't play music with Yatse, but use keyboard?

I tried two ways of playing an album using the main XBMC UI:

• Playing an album by highlighting the album name & bringing up the content menu, and choosing 'Play'
  This is slow, UI hangs for ~10-15 seconds or so before music starts
  
• Playing an album by going into track list and hitting select on first track
  Much faster, takes 4 seconds before music starts, no UI hang
  

However, it was never this slow generally on Frodo

In your logs I can see Yatse is still active, have you tried disabling Yatse completely (on all devices) and then tested if you still have the same delay when using the keyboard to start playback?

Actually, the easiest way to temporarily disable Yatse completely would be to disable the Webserver in XBMC Settings (Allow control of XBMC via HTTP -> disable).

[popcornmix]

[*]Playing an album by highlighting the album name & bringing up the content menu, and choosing 'Play'
This is slow, UI hangs for ~10-15 seconds or so before music starts

I don't use xbmc for audio (have a sonos), but I tried scanning some mp3's (about 7k), and browsing seemed fine.
Pressing context menu then play on a album took about a second.

The slowest was context menu then play on an artist with several album (295 tracks) and that started in about 4 seconds.

Yes, going into "songs" list took a while, but that's kind of expected. Albums/Artists views were quick.

I'm guessing there is another factor that is adding to the delay, but I'm not sure what it is yet (possibly yatse related).

[Martijn]

It's creating the playlist part.
go into a playlist and hit play all starts pretty quick.
select playlist and then hit play you will have to wait a while. this happens on all platforms