Posts: 385
Joined: Oct 2011
(2014-01-19, 20:42)nickr Wrote: @jacintech.fire this is an open source project, and as such developers itches tend to get scratched.
Can I suggest placing a polite suggestion in the "feature suggestion" subforum, where some itchy developers may see it and pick it up. If no one wants to, your coding efforts will no doubt be welcomed.
Also you keep saying that management of your media is easy and your 8 year old can do it. However in post 1 you said Quote:As you can imagine, it has become increasingly resource intensive to manage such a large setup
Yes; but not because of the Storage solution I am using. Another added advantage of using an object store is that I can better manage the acquisition, processing and management of new media. The word setup refers to the library; less so to the storage...
Thank you kindly for your suggestion. I thought it would help to float the idea in the general help section to get some good feedback before I post it on the developer section...
Posts: 17,855
Joined: Jan 2011
Reputation:
1,055
Milhouse
Retired Team-Kodi Member
Posts: 17,855
2014-01-19, 21:14
(This post was last modified: 2014-01-19, 21:18 by Milhouse.)
You still haven't explained how an object model would help with any of the problems you've mentioned - problems, I might add, that I don't have with my fully automated media acquisition system based on a non-object filesystem. The problems are trivial, when given a bit of thought (though not much, just keep it simple...)
How, exactly, would an object store make it easier to manage acquisition, processing and management of media when that task is already a piece of cake (our would be with a sane directory structure and here we are back at the fundamental problem with your setup...)
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.
Posts: 385
Joined: Oct 2011
(2014-01-19, 21:14)MilhouseVH Wrote: You still haven't explained how an object model would help with any of the problems you've mentioned - problems, I might add, that I don't have with my fully automated media acquisition system based on a non-object filesystem. The problems are trivial, when given a bit of thought (though not much, just keep it simple...)
How, exactly, would an object store make it easier to manage acquisition, processing and management of media when that task is already a piece of cake (our would be with a sane directory structure and here we are back at the fundamental problem with your setup...)
Can we try this another way?
Let's assume XBMC already has native support for an Object Storage model; now can you think of one (or few ways) this support can be used to drive further development of XBMC?
In short, what would both the everage user with a 200GB NAS or some idiot like myself with a 512TB rig (regardless of the merits of his storage model) use an Object Store within the context of XBMC?
Think about it thay way, then decide if it has merits...
Posts: 17,855
Joined: Jan 2011
Reputation:
1,055
Milhouse
Retired Team-Kodi Member
Posts: 17,855
No honestly, you tell us - this is your baby. I'm ready to read and learn. I've solved all my problems in the traditional way with minimal effort (literally, two shell scripts). Now tell us how much better life will be with an object store instead of a traditional file system, or how an object store simplifies "acquisition, processing and management" of new media.
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.
Posts: 385
Joined: Oct 2011
2014-01-19, 21:56
(This post was last modified: 2014-01-19, 21:57 by jacintech.fire.)
(2014-01-19, 21:37)MilhouseVH Wrote: No honestly, you tell us - this is your baby. I'm ready to read and learn. I've solved all my problems in the traditional way with minimal effort (literally, two shell scripts). Now tell us how much better life will be with an object store instead of a traditional file system, or how an object store simplifies "acquisition, processing and management" of new media.
Oh no. After I have endured such abuse? Nah-ah. I would require the following admision: I (insert name) do not quite understand the concept of an Object Store, as opposed to traditional files and filesystems. Furthermore, I also do not understand how such functionality can benefit both the average and expert XBMC user base...
Posts: 385
Joined: Oct 2011
I sure am...but I don't have the resources (or familiarity with XBMC source tree) to do this on my own.
Setting up an Object Store and populating with data is doable (difficult but not impossible). Where XBMC comes in is in its ability to access that data natively.
There is no point on me going off on my own half-baked and choosing an Object Store provider, only to find out that should XBMC decide to embrace the concept, their API binding is coded to a different provider...
Posts: 253
Joined: Dec 2010
Posts: 385
Joined: Oct 2011
@macrho, @
edrikk,
I rather not add further fuel to the fire. I will write up a feature proposal and submit it to the proper forum.
Once again, my most sincere thanks for your comments and insights.
Kind regards,
Posts: 257
Joined: Jan 2011
Reputation:
5
shadow
Senior Member
Posts: 257
@jacintech.fire Just so you know you can send uncompressed Blu-rays through powerline networking but you would have to change from windows shares to NFS it is way faster. I do all the time to my bedroom Raspberry Pi. My Powerline adaptors are even only the cheaper 10/100 versions not the gigabit (since the Pi is also only 10/100).
Posts: 385
Joined: Oct 2011
@
shadow,
I have not tried NFS since the late 1990s; I can only imagine how much it has improved since then.
I managed to stream uncompressed BluRay once or twice; but I would encounter issues every once in a while; and since I had already automated the BluRay/DVD processing with handbrake, I abandoned uncompressed folder format in favor of a "Matryoshka" (Matroska) container...