MythTV General Discussion and Support

[ltd73]

Originally Posted by phreeky82

I may have complained open it a bit much, but thus far I've begun to develop a tidy bit of code for web-based frontends that I'll release open source, and FYI I have actually started adding to the protocol pages in the wiki (which, btw, IS documented, but appears to have been not updated for a very long time and is incorrect in many places).

ok, lets look at this a different way.
what ARE you trying to do with the protocol? why do you need to touch it at all? are the perl bindings insufficient for you?
can't you use the (existing) perl/php libs that are part of mythweb?

i've found the myth folks more than happy to accept changes/constributions. you just open a ticket, attach your diff & someone applies it.

i've got multiple code commits into myth this way.

Originally Posted by phreeky82

A large reason for me mentioning it is that the lack of doc, and "open source" projects where the doc is either not published or more likely doesn't really exist, isn't overly professional and not truly open source in nature IMO. So sorry for having a bit of pride in my work and not a fan of the way certain projects are run - and for still making an attempt to contribute.

generally speaking, most people who write code hate writing documentation.
given noone gets paid for this stuff, i am not surprised the doc might be lacking. you get what you pay for.

[phreeky82]

Originally Posted by ltd73

ok, lets look at this a different way.
what ARE you trying to do with the protocol? why do you need to touch it at all? are the perl bindings insufficient for you?
can't you use the (existing) perl/php libs that are part of mythweb?

I would prefer to not include code of that nature in my project.

i've found the myth folks more than happy to accept changes/constributions. you just open a ticket, attach your diff & someone applies it.

I honestly feel that mythweb needs what is effectively a re-write rather than small changes here and there. But hey, I'm not going to hold onto my developments and not share them, I'll release them.

I'm sorry if I sound like I don't appreciate the work of the myth developers, I certainly do. They've developed a fantastic piece of software that for the most part works.

I guess I've been privileged enough to generally work on software projects that are strictly documented and professional in nature. I'm also a big believer in documentation - some people even say it's more important than the code itself - and I personally feel that it's a fundamental part of software development.

[barney]

What exactly is mythweb lacking?

There was a complaint earlier that it's slow? I don't find that at all. It's very quick for me, and does everything I could want it to. I am still to investigate streaming, but the ability to view the guide, set a recording schedule, view the status of the backend and adjust some (limited) settings from anywhere in the world is perfect!

Calls for a complete rewrite seem a bit extreme.

[phreeky82]

Originally Posted by barney

Calls for a complete rewrite seem a bit extreme.

Well I'm not calling for anyone else to re-write it, I'm instead looking at writing a similar thing myself instead. After all, like ltd73 stated, they did it for free, can't exactly expect them to do anything as such.

[barney]

Originally Posted by phreeky82

Well I'm not calling for anyone else to re-write it, I'm instead looking at writing a similar thing myself instead. After all, like ltd73 stated, they did it for free, can't exactly expect them to do anything as such.

And the reason for doing so is.....?

[phreeky82]

Originally Posted by barney

And the reason for doing so is.....?

I initially wanted to make improvements and fix some bugs. But the code is difficult to follow (i.e. not an overly neat overall structure), and had bugs that seemed to be introduced due not to silly typos/mistakes, but fundamental design decisions.

My main problem with the myth project though is the protocol. The Myth team do know this is a problem though, they've stated it on the wiki. The mythweb project doesn't provide a very good level of abstraction from the protocol either though, which I think needs to be addressed in a system that is likely to have a long lifetime.

[ltd73]

Originally Posted by barney

What exactly is mythweb lacking?

i run svn top-of-tree mythtv, the mythweb there is light years ahead of what was/is in 0.21.

like you i don't get phreeky82's issues...

Originally Posted by phreaky82

My main problem with the myth project though is the protocol.

what do you think it should be? not a binary protocol..?

[phreeky82]

Originally Posted by ltd73

what do you think it should be? not a binary protocol..?

What do you mean by "binary"? It's mostly UTF8 string command based. It has no support for growth with future versions while remaining backward compatible at all. There is very little documentation, and a lot of the existing documentation is dated and/or wrong. Like I stated earlier, even the myth site indicates they believe it needs to be replaced.

edit: bit more info FYI...

The backend protocol also doesn't actually provide access to a heap of information, and therefore requires both a connection to the backend (typically port 6543, command based like stated above), and also direct access to the mysql database (usual mysql access method). The backend protocol provides no method of authentication (no actual security). An example of data you don't appear to be able to get via the backend protocol is program listings - by "don't appear", I mean there is no info on it, I'm yet to actually look through the backend source to check if it's possible.

[bestboy]

I'm currently building a multi-purpose box and looking at running MythTV on Slackware 12.

Can anyone recommend me the best way to partition a 640GB hard drive?

[ltd73]

Originally Posted by phreeky82

What do you mean by "binary"? It's mostly UTF8 string command based.

the 'request' is text/strings based, the responses can be binary based on what the request is.

Originally Posted by phreeky82

It has no support for growth with future versions while remaining backward compatible at all.

so what? you don't run different versions of frontend/backend, you keep them in sync.

there are a variety of external progs that can operate across multiple protocol versions based on capabilities of each version.

Originally Posted by phreeky82

The backend protocol also doesn't actually provide access to a heap of information, and therefore requires both a connection to the backend (typically port 6543, command based like stated above), and also direct access to the mysql database (usual mysql access method).

some people have proposed a generic "wrap sql inside the protocol" - thereby meaning you no longer need mysql libs on frontends - but .. while that might seem nicer on face value, what value does it actually provide?
what problem is it solving?

Originally Posted by phreeky82

The backend protocol provides no method of authentication (no actual security).

yep. fair point. so what?

Originally Posted by phreeky82

An example of data you don't appear to be able to get via the backend protocol is program listings - by "don't appear", I mean there is no info on it, I'm yet to actually look through the backend source to check if it's possible.

the perl/python bindings i listed earlier 'abstract' accessing these things.
you dismissed them as being useless already earlier.

its easy to be part of the peanut gallery and throw rocks. but without providing an ALTERNATIVE CODE those folks that have contributed are more than entitled to refuse to listen to whining folks.

[phreeky82]

Originally Posted by ltd73

the 'request' is text/strings based, the responses can be binary based on what the request is.

Yes, mostly string based though. And there is silly things, like the delimiter used is []:[], but it doesn't appear that []:[] appearing in a response item is even escaped in any way.

so what? you don't run different versions of frontend/backend, you keep them in sync.

I personally think that's bad though, and that you should be able to run different frontend/backend versions. It's designed for muliple backends and multiple frontends these days (primarily multiple frontends though), and when you're talking minor protocol changes preventing them from working together it gets a bit silly.

A high level protocol certainly should be able to include feature expansion whilst remaining backward compatible, without even needing to specifically code for previous versions in most cases. The control socket connection isn't exactly bandwidth hungry, so while I accept that the data transfers need to be nice and lean, the control protocol could easily include a bit more complexity.

there are a variety of external progs that can operate across multiple protocol versions based on capabilities of each version.

Yeah but they've had to specifically work that into their progs in most cases.

some people have proposed a generic "wrap sql inside the protocol" - thereby meaning you no longer need mysql libs on frontends - but .. while that might seem nicer on face value, what value does it actually provide?
what problem is it solving?

Yeah I'm not a fan of that, that's a bit of false abstraction too really. I'd like to see the backend protocol providing functionality for all the relevant commands, with accommodation for certain sorting/indexing/grouping attributes to ensure it's still efficient (i.e. if requesting a grouping, backend can request the grouping in its SQL calls still, rather than relying on the frontend having to group itself).

yep. fair point. so what?

It's a fairly simple feature, and the frontends typically still require a password anyway because they have to connect to the mysql database.

the perl/python bindings i listed earlier 'abstract' accessing these things. you dismissed them as being useless already earlier.

Well I didn't call them useless, I just think it's lacking.

its easy to be part of the peanut gallery and throw rocks. but without providing an ALTERNATIVE CODE those folks that have contributed are more than entitled to refuse to listen to whining folks.

Like I said earlier, I'll release my code, no drama there. And in such a way that a complete remake of the protocol could allow a new version to be "dropped in" as such. I'm not one to critisise without being prepared to help out/offer solutions.

[phreeky82]

No real progress, been busy Got a new job

However, I have come across a strange issue. Not sure if it's behaviour by design, a bug, or there's an option that is set be default causing this. Running 0.21, frontend (backend on a separate machine), if the recording folder as set in the BACKEND (i.e. /myrecordings) also exists in the FRONTEND machine itself (i.e. /myrecordings), live playback fails with an "error was encountered while displaying video".

FYI, my actual situation is that my backend recording folder is /mnt/big/mythtv/recordings, and I have that shared via samba and mount it to that same folder on my frontend, as it's my "big" drive that I want to access from anywhere. My solution of mounting it to /mnt/server/big/ instead of /mnt/big on the frontend does work. Quite odd, but easily worked around, couldn't find anything about it via google.

[rees]

just a question re what would be the better processor for a myth frontend / backend;

i'm looking at either a 2ghz quad core or a 2.5ghz dual core, how multithreaded is myth and which one would be the better option?

[ltd73]

Originally Posted by phreeky82

No real progress, been busy Got a new job

However, I have come across a strange issue. Not sure if it's behaviour by design, a bug, or there's an option that is set be default causing this. Running 0.21, frontend (backend on a separate machine), if the recording folder as set in the BACKEND (i.e. /myrecordings) also exists in the FRONTEND machine itself (i.e. /myrecordings), live playback fails with an "error was encountered while displaying video".

FYI, my actual situation is that my backend recording folder is /mnt/big/mythtv/recordings, and I have that shared via samba and mount it to that same folder on my frontend, as it's my "big" drive that I want to access from anywhere. My solution of mounting it to /mnt/server/big/ instead of /mnt/big on the frontend does work. Quite odd, but easily worked around, couldn't find anything about it via google.

probably not a bug in mythtv. frontends can either stream from the backend by opening the file itself, or by streaming it across myth protocol.

it prefers the former - and likely the frontend 'sees' the file so tries to open it.
likely due to how shares with oplocks are done in SMB that the open ends up trying to open the file for exclusive use - and fails...
you could strace it & see. there is a setting somewhere to set the preference.

[kreegor]

Originally Posted by rees

just a question re what would be the better processor for a myth frontend / backend;

i'm looking at either a 2ghz quad core or a 2.5ghz dual core, how multithreaded is myth and which one would be the better option?

If you are using it as a dedicated HTPC (which I believe you should) then you can go with the dual core. I have an E2160 which is a 1.8 dual core and that can handle myth no problem at all.