• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 22
Native Object-Based Storage Support for XBMC
#16
Bizarre yes; but it works flawlessly :-)
What let to inquire about the object store model is the inherent benefits it offers. Yes is new and different and it requires a new way of thinking...but its benefits are undeniable...
Think of the benefits of using MYSQL instead of local store for media metadata. Imagine that same level of control over the content itself...
Reply
#17
Just as an aside: Consider that every advance that underpins Western civilization arose because at some point someone said "I wonder what would happen if I try it this way..."
Reply
#18
I totally understand why you'd want to try an alternative solution given the pigs ear you've created, but there are straight forward solutions you could use - tried, tested and proven and in the case of ZFS an Enterprise-grade solution - without going for something exotic and with dubious benefits.
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
#19
You still haven't answered why this is unsuitable to do at the OS level? (Mind you you could say that about smb and nfs.)
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Reply
#20
You gotta start thinking differently. You are still stuck with the idea that a media stream is a file and belongs in a directory in a hard drive...but a media stream is an object that should have continuous and persistent access...
Reply
#21
@nickr,
All I am asking is for XBMC to be able to interact and manipulate an object store. I am not asking for XBMC to develop its own object store...
There are already several Object Store implementation to choose from. All open source...
Reply
#22
sorry man, I think I didn't quite get it yet. it's just that I don't really feel your idea. what would be the advantage instead of just using the methods on OS level? you are speaking about the XBMC userbase not being average users. this may be right because many of us have there own home servers, NAS-devices and multiple clients throughout the house and whatever. but keep in mind that your gigantic rig is a very rare individual case. I don't think the XBMC Team will include a feature that only 0,01% of the userbase want to use.
HTPC LibreELEC 9.0 - Xperience1080+
RPi3 LibreELEC Milhouse build - Arctic Zephyr
Reply
#23
I firmly believe you need to rethink your fundamental approach to storage before implementing an object storage layer. Whatever benefits you think object storage may give you, it's undeniable that your current storage implementation is totally insane. And it's the insanity of this implementation that now seems to have set you off on this quest for object storage. Perhaps if you took a step back and reassessed your implementation you might be able to see that there are easier/better solutions that don't require an object storage layer, although they might require you to start from scratch (you've got backups, right? Wink)

Of course if you don't have a backup, which means you're stuck with the mess of drives and partitions you've created, then I can kind of understand why you would now hope that object storage might help you to make sense of it all.

Personally, I would look at starting again with a more rational storage solution that could be expanded as you add extra disks, allowing you to transition your data across incrementally.
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
#24
The fact that everybody keeps on saying "why on earth would you want a 512TB storage solution..." or a variation thereof tells me I may have something here...

BTW, RAID or any similar solution has been obsolete for several years now...so until I could find something better I chose not to implement anything...

I have always partitioned my HDDs. It's a force of habit and I have not found any reason not to...

The fact that no ones has figured out why an object store would be a better approach tells me I may be in the right path...
I could tell you all what the ultimate end would be; but where is the fun in that...? :-)
Reply
#25
This is a wind up, right?
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
#26
@freem@n,
All I am doing is asking for a mechanism to access and manipulate the already existing object stores directly from xbmc...rather than using some mapping mechanism....

@MhouseVH,
No this is a legitimate query...I am just blown away to nobody has raised this issue before...to me is soooo obvious, is funny
Reply
#27
(2014-01-19, 11:43)jacintech.fire Wrote: @MhouseVH,
No this is a legitimate query...I am just blown away to nobody has raised this issue before...to me is soooo obvious, is funny

I think people are wondering why you think it's so clever to have multiple layers of metadata to access what is (or should be) mostly static and well structured storage.

If you hadn't codsed up your storage in the first place I'm pretty sure this discussion wouldn't be taking place. And that's most likely why nobody has raised this issue before, because nobody else has created the storage horror that you have...

And do you really have 128 drives spinning with no redundancy? I now kind of hope you also think backups are obsolete (but that would be cruel!) Wink
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
#28
its not obvious at all why on earth xbmc would need to support this directly. You can do it on the OS level!
Besides that I really don't see a benefit over a proper raid setup.
Reply
#29
@wsnipex,
You in order to use the object store, you would need either a mapping mechanism to expose the objects as files to XBMC or native support for the object store by XBMC.
As I have said before, I am not asking for an object store implementation just an API (or rather, an "API Hook") to allow XBMC to access and manipulate the object store directly. This could be as easy as an internal object to file mapping mechanism ...
Reply
#30
Im not here to join this discussion, Im posting this as a reference for the OP He should read its especially the setup part.

http://www.admin-magazine.com/HPC/Articl...Filesystem
Reply
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 22

Logout Mark Read Team Forum Stats Members Help
Native Object-Based Storage Support for XBMC5