Request / suggestion.. images and meta data

Nosferatu

Member
I would like XMBC on the humax box. There we go :) bye!

...

Ok, Seriously,

I did not expect the interface on the humax box to be so basic. I didn't exactly expect fancy graphics or anything like that but I would like to start a serious discussion about this.

I've spent most of my day in and out of

xmbc
mediatomb
twonky *cries*

EMDB
PVD
doublefeature
media center master

and probably some other random apps that never did what I was looking for.

In the past I've tried out some different media servers and currently I have a web facing subsonic server with a fully working browser with cover art indexing over 100k of tracks. I have an AppleTV that can not only display thumbnails from media on remote drives but will also bring in synopsis etc from an external database.

What I want to do with the Humax, is index all my media together, including covers and metadata and allow it to be browse-able on the PVR.

Click, see info and image,
click, play movie

simples.

Yet apparently it's not! In fact it's impossible! Is it really? I know everyone is doing this on their free time and I really do appreciate that but from my understanding of computing - it's certainly not impossible and once a template was created it should be reasonably simple.

Here is the way I figure it would or could work...
Using XMBC or media centre master (coincidentally the apps I had the most success with regarding automation) You would gather all your images and metadata and compile it into a library. On the most basic level, you would need to do a quick reindex anytime you added or removed a film.

On the Humax device, you would have a simple web interface that can read said database from the network (or maybe it can fetch and cache the data) showing the user a list from that database, allowing the user to drill down by genre, rating, actor, etc - view details about the film and play to .. well, play it on the screen.

I probably don't have the expertise required to code this, otherwise I would have spent less time talking and more time coding, however is there nothing that could be modified to suit?

With the full XMBC running on a raspberrypi - is it really too cpu intensive? Is this more a restriction on the DLNA side of things? Maybe I'm missing something, I've only just got mediatomb working so I'm going to have a fiddle with that.

To be honest I did actually have difficulty identifying an app that could pull all this information automatically, it doesn't seem to be quite as common as mp3 tagging was. Anyway, I highly recommend the above two apps for doing that en-mass however now I just need to work out a solution to make it useful.

I will add, I personally don't see the point of XMBC unless you have it on a STB. I'm sure there are a million use cases and reasons why I'm wrong - however I do feel that some of the plugins and indexing setups are some of the most efficient I've seen. Just a shame I cant merge the XMBC ratings that I pulled from IMDB with the ratings in windows lol. But that's a major digression .

I realise there are people that find the idea of covers or thumbnails for movies irrelevant - personally I call it unprofessional.


Thanks for listening :)
Ian.
 
I think the mods should move this to the custom firmware section. Update: has been moved.

A few quick comments: XBMC stands for "X-Box Media Centre" - there are versions which run on various games consoles for example. Yes it is too processor intensive, the Pi has a powerful CPU and plenty of RAM, the HD/HDR-FOX does not. The bulk of the clever stuff in the 'FOX is performed in dedicated hardware dedicated to the specific purpose (and not available for general processing).

As far as making the Humax do anything different on the user interface side is concerned, we have very little means to access video, no sound at all, and of course there is no keyboard input. You should have a look at the custom firmware and the portal-xtra1 package in particular to appreciate the limitations.
 
ah, thanks - sorry yeah I was supposed to put it in the custom section.

Yes, I mention the Pi but I guess if there is no interface to the media side of things then that would be an issue. I notice there are now 11 builds for different architectures, so I find the xbox part of XBMC pretty irrelevant.

cheers!
 
It is possible to display a web page, I'm not sure how but the custom portal has a Google demo on it (just lacks a means of getting anything other than numbers into the search box - it might work with a USB keyboard). You might therefore think that all is not lost if the actual content of the web page can be constructed somewhere - a series of thumbnails and links to media.

What you need is somebody willing to champion the idea and put some coding effort in.
 
Xbmc was discussed a good while ago. The humax is just not powerful enough and we cannot interface with the hdmi or sound outputs which is why there has been no custom GUI from my understanding.

Xmbc started out life on the Xbox 1 which is where it obtained its name. Since then, the devs behind it have dropped support for the original Xbox completely because it was not powerful enough anymore and have ported the codebase over to other platforms such as windows, Linux, apple tv, android and even ios. But all of these platforms are all more powerful than the T2.
The only reason the T2 can decode HD video is because it is handled by a dedicated chip.
 
Ps. I put the google link on the portal to demonstrate the complexity of getting a web page working with the remote.
 
am I right in saying that the Pi has a dedicated chip also? I realise this is nothing, even if the humax had a dedicated chip you'd still need to interface with it. I'm just curious

What CPU does the Humax HDR-FOX T2 Freeview+ HD Twin Tuner with 1TB Recorder have? I notice some of the open hardware have a 300mhz Mips chip, please don't tell me the FOX T2 has the equivalent of a 1990s SGI workstation in it?
 
As for the Pi, I'm not sure but I doubt it has hardware codecs except what might be included in the graphics chip. The hardware in the HDR-FOX is listed in the Wiki HERE (click). It's design goal doesn't require a lot of processing power, so it doesn't have much.

In summary, the Pi has a 700MHz ARM6 core (clocked up to 1GHz dynamically), and the Humax has a 400MHz MIPS core.
 
thanks, I did actually bother to look but I guess I've not quite woken up yet!

400mhz , ok... no spec on cache

Chris, you said you had put google on the portal to demonstrate the issues with getting a simple web page up with the remote. Is this because of the SDK?

I'm sorry if I'm covering old ground - If were to completely wipe the contents of root would the box

A) be dead ?
B) have basic software to bootstrap OS on USB
C) automatically revert back to default setup?

When the box boots, am I right i saying we don't have direct access to the firmware and that all we are doing is attaching the CFW onto it as a kinda extension? Does that explain why we have limited functionality?

I notice in the developers section we do have quite a few sets of kit for basic linux compilation. What has been the most complex software you've managed to get compiled? I can see why this would be difficult but it's frustrating that there is nothing.

Can you describe for me what happens when you browse a DLNA server? do we know? and is that template available?

cheers.
 
ok, so that broadcom chip, has a variety of setups, some of which are dual core. Some are dual core with the 2nd core disabled. Do we know if this is the case with the humax? It appears the Tivo series 4 uses the same cpu.

Here is the PROM log of that cpu on another device


and here is the PROM log from another device with the 2nd core enabled within Linux
Code:
++ CPU info ++
system type^I^I: BCM97xxx Settop Platform 
build target^I^I: 7413-smp

processor^I^I: 0 
cpu model^I^I: BMIPS4380 V4.4  FPU V0.1 
cpu MHz^I^I^I: 402.43 
BogoMIPS^I^I: 402.43
wait instruction^I: yes 
microsecond timers^I: yes 
tlb_entries^I^I: 32 
extra interrupt vector^I: yes 
hardware watchpoint^I: no 
ASEs implemented^I: mips16 
VCED exceptions^I^I: not available 
VCEI exceptions^I^I: not available 
RAC setting^I^I: Unknown 
unaligned access^I: 0 
rdhwr/brdhwr traps^I: 0 / 0 
cycle counter frequency^I: 27046875

processor^I^I: 1 
cpu model^I^I: BMIPS4380 V4.4  FPU V0.1 
cpu MHz^I^I^I: 402.43 
BogoMIPS^I^I: 402.43
wait instruction^I: yes 
microsecond timers^I: yes 
tlb_entries^I^I: 32 
extra interrupt vector^I: yes 
hardware watchpoint^I: no 
ASEs implemented^I: mips16 
VCED exceptions^I^I: not available 
VCEI exceptions^I^I: not available 
RAC setting^I^I: Unknown 
unaligned access^I: 0 
rdhwr/brdhwr traps^I: 0 / 0 
cycle counter frequency^I: 27046875

EDIT: I'm an idiot, both cores are enabled and you can tell that from the wiki DOH,
 
Only one or two people here might know the answer to how the firmware is partitioned. You would depend on not wiping the firmware loader.

The Humax native code is based on a Linux kernel and has some open source elements, but the actual nuts-and-bolts are in a closed-source executable and the hardware is accessed directly (not via standard Linux device drivers).

As far as DLNA is concerned, you can Google as well as the rest of us. Nothing posted on the forum would suggest it has already been researched.

If you want to reach further than has been done so far, you are welcome to try.

PS: Why would Humax licence the second core?
 
Thanks Black hole, although I was asking anyone else here had actually found that information and had it off hand. Cheers for the sarcasm though.
 
yeah, your right I'm being silly lol although the information doesn't match what we have on the wiki:

Code:
Humax HDR-Fox T2 (humax) 1.02.29/2.14

humax# cat /proc/cpuinfo
system type             : BCM97xxx Settop Platform
build target            : unknown
processor               : 0
cpu model               : BMIPS4380 V4.4  FPU V0.1
cpu MHz                 : 402.43
BogoMIPS                : 402.43    ( udelay_val : 201216  HZ = 1000 )
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : no
ASEs implemented        : mips16
VCED exceptions         : not available
VCEI exceptions         : not available
RAC setting             : Unknown
unaligned access        : 275759
rdhwr/brdhwr traps      : 0 / 0
process migrations      : 7739
processor               : 1
cpu model               : BMIPS4380 V4.4  FPU V0.1
cpu MHz                 : 404.48
BogoMIPS                : 404.48    ( udelay_val : 202240  HZ = 1000 )
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : no
ASEs implemented        : mips16
VCED exceptions         : not available
VCEI exceptions         : not available
RAC setting             : Unknown
humax#
 
What I get from what you're saying, since Humax are using proprietory blobs for the interfacing, even if we were to get more tools and apps to compile on the box we'd either need to rewrite our own drivers etc from the ground up or somehow gain magical access to the proprietary blobs.

So my last question, Do these proprietary binaries access the same kernel that we do? or are we effectively virtualising another kernel on top of the current firmware? I'm happy to stop biting legs after that if someone can tell me :) cheers (I'm guessing that would also answer my own questing regarding wiping 'root')
 
no, from black hole halfway up the page

Black hole
Only one or two people here might know the answer to how the firmware is partitioned. You would depend on not wiping the firmware loader.

The Humax native code is based on a Linux kernel and has some open source elements, but the actual nuts-and-bolts are in a closed-source executable and the hardware is accessed directly (not via standard Linux device drivers).
 
You could have a crack at decompiling (and then decyphering) the Humax code from a firmware update file, but it is likely to be very hard work. Even probing the hardware is going to be of limited use, as much of the data traffic will be hidden inside the SoC.

At a guess (af123 will know a lot more), the humaxtv process only uses the kernel for the normal OS type things, eg file system. Direct programmed access to hardware registers is a lot more efficient than OS drivers when you do not have compatibility with a multi-processing environment to worry about.
 
Back
Top