• 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  • 12
Video of latest xbmc code on Raspberry Pi
#61
(2013-09-29, 12:37)MediaPi Wrote: Although I commend the Raspberry Pi and use one as my main HTPC source. In terms of hardware its already being beaten on price and performance. The quad core boxes are selling for around £50. Your optimising it to the death and by the time your finished you can pick up a quad core beast that will cost the same or lower and have GUI performance x8 minimum. Whats the point in optimising it when consumers will just jump ship. All they care about is price/performance. and all your efforts will have been for nothing??
I couldn't disagree more. Have you considered the resource wastage of moore's law filling up landfills everywhere with year after year of junk? Ever seen videos of the illnesses kids inherit in the third-world junk heaps where child labor is used to extract any traces of precious metals still available in our 'first world' junk?

Here's one example:

http://www.cbsnews.com/stories/2008/11/0...9229.shtml

In addition, does XBMC even support multi-threading and or GPU acceleration in all these newer boards you are referring to? The Pi's can be used for more than just XBMC but everyone needs recreation time in between figuring out GPIO, I2C and all that stuff.

Furthermore, how many of the boards you refer to have such a high-quality, inexpensive camera add-on module available? With that module, it's foreseeable that all the little Pis out there can become HDTV-top video chat platforms. Whilst that may not be done through XBMC, why couldn't it be? The pi has built-in h264 encoding!

Speaking of codecs, how many of those 50 pound boards come with codec licensing for $5 each? Those extra cores may decode various codecs without licensed dedicated hardware decoding but how much extra power do they use to do it?

There's nothing wrong with optimization. It's purely lazy to rely on hardware upgrades. That produces situations where the software could full of bitrot and crash left right and centre which is exactly what XBMC formerly used to do. It's bad enough that XBMC targets over half a dozen platforms that distribute developer load instead of focusing on one, but if you also throw 'good enough' code quality on the latest hardware into the mix, it's just irresponsible in my view.

And then there's the old simple fact: popcornmix and others are optimizing because they want to, and they can!
Reply
#62
(2013-09-29, 13:05)popcornmix Wrote:
(2013-09-29, 12:37)MediaPi Wrote: Although I commend the Raspberry Pi and use one as my main HTPC source. In terms of hardware its already being beaten on price and performance. The quad core boxes are selling for around £50. Your optimising it to the death and by the time your finished you can pick up a quad core beast that will cost the same or lower and have GUI performance x8 minimum. Whats the point in optimising it when consumers will just jump ship. All they care about is price/performance. and all your efforts will have been for nothing??

There are a lot of Raspberry Pi devices out there. Due to it's business model (education), it's a long term platform - it will be supported for years.

While xbmc isn't a primary goal of Raspberry Pi, I'm in a unique position of being able to edit the GPU firmware and xbmc code to fix problems.
And I have a Pi in my living room which is the only thing I watch videos on, so I have an incentive to improve it.

The cheap android boxes will come and go. All are, I believe, not fully functional (e.g. missing CEC, 24Hz switching and DTS/AC3 passthrough), and may well be abandoned by manufacturers before they do work.

No doubt more powerful boxes will continue to appear, and android support will improve, but I'd like to keep the Pi competetive for as long as is possible.
Well said popcornmix!

Let's not forget as well that the goals of the Pi may be primarily education but the more Pi XBMC users out there, the more sales, the more money available to dedicate to that education goal. Once again as well, kids and adults alike deserve recreation time. Not everyone wants to spend every day, every minute learning! If a kid gets a Pi for a present from a well-meaning relative and that kid initially has no interest in electronics or programming, they can still use the unit for however long and as we all know, the interests of kids vary over time, so being that the Pi is multi-puprose, the kid who one day wasn't interested, might well be 6 months down the track!

MediaPi your perspective is very short sighted to say the least. XBMC on the Pi can save a lot of LCD (not LED or 'smart') era flat TVs from landfill for many years. Only 4K might threaten the usefulness of the Pi as an XBMC platform.

popcornmix is also correct in that every one of those boxes/boards you are suggesting would potentially either come with, or need, yet another remote control because they don't bother support CEC. The Pi saves landfil again there.

(2013-09-29, 13:13)popcornmix Wrote: I believe the whole directory is iterated, and then each file is compared with a valid subtitle filename, so the time taken is proportional to the number of files in the directory.
With a thousand moveies, each with a collection of artwork, nfo files and subs, I could imagine this taking a couple of seconds (although I keep things as hieracrhical as possible, so haven't tried this).
That makes sense, except that AFAIK artwork (downloaded from metadata sources like TMDB) is generally stored separately to the movie files source location, isn't it? I thought that posters and background metadata was given a generic filename and stored in the userdata folder? Sorry if this seems nit picky. I think your broader point is probably quite valid. I previously thought it might have been better to keep the database basename strings as short as possible to reduce SQLite database size as a bottleneck but I guess since I'm storing my media on a NAS and currently accessing it over SMB (I hear you in terms of NFS being faster thought), then I guess file / folder existence checking might be an issue.
Reply
#63
(2013-10-01, 17:31)popcornmix Wrote: Spider-man 3 is actually very unusual. It is a jpeg encoded with CMYK colourspace (jpegs are generally YUV).

The software decoder seemed to handle it OK though (even if it's not entirely happy), and I downloaded it from themoviedb.org so others might also pick it up (or similar CMYK encoded files). Could the Pi fall back to the software decoder for files like this?

If the Pi can't decode this kind of image, what would be _really_ useful is for the name of the image file to be logged as an ERROR so that the user can act on it.

(2013-10-01, 17:31)popcornmix Wrote: I imagine the current timeouts only occur in complex scenarios (mutliple concurrent jpegs being encoded/decoded).
If you have a repeatable failure I'd be interested.

Not sure which timeouts you mean, the timeouts that continue forever (I can reproduce that with "texturecache.py c movies spider-man\ 3") or the timeouts that appear when scrolling rapidly through the Movies library with Fanart view (no encoding, just decodes - everything pre-cached).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#64
(2013-10-01, 19:00)MilhouseVH Wrote: Not sure which timeouts you mean, the timeouts that continue forever (I can reproduce that with "texturecache.py c movies spider-man\ 3") or the timeouts that appear when scrolling rapidly through the Movies library with Fanart view (no encoding, just decodes - everything pre-cached).

Ah - I didn't quite understand that was what was happening, and when looking at your log I thought "Oh - more than one bitstream courrupt message" and fixed that.
That made the code behave as expected, and it falls back to software decode.

Try latest commit on newclock3.
Reply
#65
(2013-10-01, 18:21)raspberry_pd Wrote: That makes sense, except that AFAIK artwork (downloaded from metadata sources like TMDB) is generally stored separately to the movie files source location, isn't it? I thought that posters and background metadata was given a generic filename and stored in the userdata folder?

The cached versions of the original artwork are written to the userdata folder. The original artwork, if it's local, will exist alongside the media files.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#66
(2013-10-01, 19:06)popcornmix Wrote: Try latest commit on newclock3.

With these latest patches, I still get the occasional timeout when browsing fairly rapidly through 600+ Movies with Fanart view:
Code:
18:46:48 T:2876916816   ERROR: COMXCoreComponent::GetInputBuffer OMX.broadcom.image_decode wait event timeout
18:46:58 T:2902082640   ERROR: Previous line repeats 9 times.
18:46:58 T:2902082640   ERROR: COMXCoreComponent::SetStateForComponent - OMX.broadcom.image_decode failed with omx_err(0x80001000)
18:47:02 T:2796532816   ERROR: Previous line repeats 1 times.
18:47:02 T:2796532816   ERROR: COMXCoreComponent::GetInputBuffer OMX.broadcom.image_decode wait event timeout
18:47:14 T:2796532816   ERROR: Previous line repeats 7 times.
18:47:14 T:2796532816   ERROR: COMXCoreComponent::SetStateForComponent - OMX.broadcom.image_decode failed with omx_err(0x80001000)
18:47:15 T:2796532816   ERROR: Previous line repeats 1 times.
18:47:15 T:2796532816   ERROR: COMXCoreComponent::GetInputBuffer OMX.broadcom.image_decode wait event timeout
18:48:11 T:2876916816   ERROR: Previous line repeats 40 times.
18:48:11 T:2876916816   ERROR: COMXCoreComponent::SetStateForComponent - OMX.broadcom.image_decode failed with omx_err(0x80001000)
18:48:14 T:2796532816   ERROR: Previous line repeats 1 times.
18:48:14 T:2796532816   ERROR: COMXCoreComponent::GetInputBuffer OMX.broadcom.image_decode wait event timeout
18:49:00 T:2796532816   ERROR: Previous line repeats 32 times.
18:49:00 T:2796532816   ERROR: COMXCoreComponent::SetStateForComponent - OMX.broadcom.image_decode failed with omx_err(0x80001000)
18:49:03 T:2812277840   ERROR: Previous line repeats 1 times.
18:49:03 T:2812277840   ERROR: COMXCoreComponent::GetInputBuffer OMX.broadcom.image_decode wait event timeout
18:49:13 T:2820666448   ERROR: Previous line repeats 2 times.

And when viewing the CMYK Spider-man 3 fanart:

Code:
18:49:13 T:2820666448  NOTICE: Thread BackgroundLoader start, auto delete: false
18:49:14 T:2796532816  NOTICE: Previous line repeats 1 times.
18:49:14 T:2796532816   ERROR: COMXCoreComponent::GetInputBuffer OMX.broadcom.image_decode wait event timeout
18:49:22 T:2796532816 WARNING: COMXImageFile::GetCodingType Only YUV images are supported by decoder
18:49:22 T:2796532816   ERROR: COMXImageFile::ReadFile nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Spider-Man Collection/Spider-Man 3 (2007)[BDRip]-fanart.jpg GetCodingType=0x7fffffff
18:49:22 T:2796532816   ERROR: CreateThumb: 0x0 nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Spider-Man Collection/Spider-Man 3 (2007)[BDRip]-fanart.jpg->special://masterprofile/Thumbnails/5/52739465.jpg () = 0
18:49:22 T:2796532816 WARNING: COMXImageFile::GetCodingType Only YUV images are supported by decoder
18:49:22 T:2796532816   ERROR: COMXImageFile::ReadFile nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Spider-Man Collection/Spider-Man 3 (2007)[BDRip]-fanart.jpg GetCodingType=0x7fffffff
18:49:22 T:2796532816  NOTICE: LoadJpeg: unable to load nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Spider-Man Collection/Spider-Man 3 (2007)[BDRip]-fanart.jpg
18:49:23 T:2796532816 WARNING: JpegIO: Error 28: Unsupported color conversion request

Despite the error messages and "unable to load" notice, a cached version was successfully created which also displayed correctly in the GUI. It's good there is a filename there though, very useful! Smile
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#67
(2013-09-29, 12:37)MediaPi Wrote: Although I commend the Raspberry Pi and use one as my main HTPC source. In terms of hardware its already being beaten on price and performance. The quad core boxes are selling for around £50. Your optimising it to the death and by the time your finished you can pick up a quad core beast that will cost the same or lower and have GUI performance x8 minimum. Whats the point in optimising it when consumers will just jump ship. All they care about is price/performance. and all your efforts will have been for nothing??
I couldn't disagree more. It's that kind of thinking (using faster processors as a crutch for inefficient code) that is saddling many of us with applications that are sluggish on fast machines. This includes many commercial applications that ought to be much more responsive than they are.

An illustrative example that I think is close to home is the very limited GPU support in mythTV. I have a semiretired 2009 macbook running mythbackend. It has a much more powerful CPU than a Pi and a GPU that is more than capable of playing back HD content, as long as you are using something other than mythfrontend. The backend has no GPU support at all, which would help with, among other things, commercial detection. The general view in the myth community seems to be the same as yours: "Who needs a GPU when you can make up for its absence with a faster computer."

You also have to respect someone who clearly finds it engaging to make something work better.
Reply
#68
@popcorn.........are you uploading a new image with the latest target files again?
Reply
#69
(2013-10-01, 19:17)MilhouseVH Wrote:
(2013-10-01, 18:21)raspberry_pd Wrote: That makes sense, except that AFAIK artwork (downloaded from metadata sources like TMDB) is generally stored separately to the movie files source location, isn't it? I thought that posters and background metadata was given a generic filename and stored in the userdata folder?

The cached versions of the original artwork are written to the userdata folder. The original artwork, if it's local, will exist alongside the media files.
Thanks MilhouseVH. Perhaps the key issue for me is that my original artwork is not "local" or I am not sure what that means. Are you referring to artwork obtained independantly of XBMC's scraping and web service functionality, and manually moved into corresponding folders yourself, which now that I think about, XBMC can use?

Perhaps this is why running your texturecache script didn't seem to do anything in the context of my setup.
Reply
#70
(2013-10-02, 06:27)raspberry_pd Wrote: Thanks MilhouseVH. Perhaps the key issue for me is that my original artwork is not "local" or I am not sure what that means. Are you referring to artwork obtained independantly of XBMC's scraping and web service functionality, and manually moved into corresponding folders yourself, which now that I think about, XBMC can use?

"local" artwork is artwork that is stored on your NAS (or your HDD), alongside your movies. Local artwork will have fileanems ending in -poster.jpg, -fanart.jpg etc.

If you don't have artwork stored alongside your movies, XBMC will go out to internet web sites and download artwork files, storing these files only in the userdata folder (in the texture cache).

(2013-10-02, 06:27)raspberry_pd Wrote: Perhaps this is why running your texturecache script didn't seem to do anything in the context of my setup.

Depends what you were trying to do!
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#71
(2013-10-02, 06:37)MilhouseVH Wrote:
(2013-10-02, 06:27)raspberry_pd Wrote: Thanks MilhouseVH. Perhaps the key issue for me is that my original artwork is not "local" or I am not sure what that means. Are you referring to artwork obtained independantly of XBMC's scraping and web service functionality, and manually moved into corresponding folders yourself, which now that I think about, XBMC can use?
"local" artwork is artwork that is stored on your NAS (or your HDD), alongside your movies. Local artwork will have fileanems ending in -poster.jpg, -fanart.jpg etc.

If you don't have artwork stored alongside your movies, XBMC will go out to internet web sites and download artwork files, storing these files only in the userdata folder (in the texture cache).

So in theory I could save the TVDB and TMDB a lot of trouble, and perhaps even speed up my library scanning a little, by storing local versions of meta images on my NAS? Cool. Hmmm, wonder if your texturecache script can convert from the cached filenames to real filenames and copy them from cache to my NAS? Smile I suspect it can, time to read the full documentation Smile

(2013-10-02, 06:27)raspberry_pd Wrote:
(2013-10-02, 06:37)MilhouseVH Wrote: Perhaps this is why running your texturecache script didn't seem to do anything in the context of my setup.
Depends what you were trying to do!

I was trying to do what popcornmix suggested earlier in this thread here might help speed things up. I lurv speed Smile However it sounds like I was fishing without bait and I can't interpret these results anyway Smile

Here's my results:

Movies
http://pastebin.com/N0MRqh6A

TV
http://pastebin.com/wG4f2GHW
Reply
#72
(2013-10-01, 21:17)misa Wrote: @popcorn.........are you uploading a new image with the latest target files again?

I'm not going to be producing regular builds. Maybe if there is a new feature I want tested, but not for every fix.

Looks like rbej has made a new build which I believe has all my latest changes in:
http://forum.xbmc.org/showthread.php?tid...pid1518755
Reply
#73
I try today newclock3 compile but i have error

http://pastebin.com/rQwQH4hG



Reply
#74
(2013-10-02, 13:51)rbej Wrote: I try today newclock3 compile but i have error

http://pastebin.com/rQwQH4hG

Fixed with this:
https://github.com/xbmc/xbmc/pull/3364
Reply
#75
(2013-10-02, 12:01)raspberry_pd Wrote: So in theory I could save the TVDB and TMDB a lot of trouble, and perhaps even speed up my library scanning a little, by storing local versions of meta images on my NAS? Cool.

Local artwork will definitely speed up scanning. It will also give you more consistent results as you will be able to select higher quality artwork. In addition, your artwork will always be available should you add another client, whereas internet hosted artwork has a habit of disappearing (this point is important when adding extra clients to a shared library).

(2013-10-02, 12:01)raspberry_pd Wrote: Hmmm, wonder if your texturecache script can convert from the cached filenames to real filenames and copy them from cache to my NAS? Smile I suspect it can, time to read the full documentation Smile

No, it can't actually - there's already the built-in library "export" option for that. However, you'll just be exporting your cached artwork, which will contain resized and lower quality versions of the original artwork so it's not really an ideal solution IMHO. You're better off using something like Ember Media Manager to organise your local artwork (using the highest quality available) and metadata.

(2013-10-02, 12:01)raspberry_pd Wrote: I was trying to do what popcornmix suggested earlier in this thread here might help speed things up. I lurv speed Smile However it sounds like I was fishing without bait and I can't interpret these results anyway Smile

Here's my results:

Movies
http://pastebin.com/N0MRqh6A

TV
http://pastebin.com/wG4f2GHW

That looks like it's working normally. For Movies, all your posters and fanarts were already cached, so nothing more needed to be cached. However for TV Shows your cache was missing 21 items so they were added to the cache. Now your texture cache should be fully populated and the GUI not wasting any more time encoding artwork as you browse through your movies and tv shows.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
  • 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  • 12

Logout Mark Read Team Forum Stats Members Help
Video of latest xbmc code on Raspberry Pi6