Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - danielk

Pages: 1 2 3 [4] 5 6 ... 11
46
Developers / Re: PNP without DHCP
« on: March 20, 2008, 05:24:12 pm »
Ah, I see... I can understand that, since you no longer had a need for it why bother following through, I have a crapload of projects that have died for that very reason. I think I may pickup where you left off if thats ok with you?  I am very interested in coming up with an alternative to detecting those devices without dhcp.

Orionsume, this would be a valuable addition to LinuxMCE even if Hari doesn't need it anymore. The DHCP server one of the things that scares people casually testing LMCE and makes a Knoppix type try-it-before-you-install-it DVD a tough thing to do. This would also help familiarize you with the PNP process, which Dan Damron has been investigating as well (for Insteon auto-detection.)

Of course, there are other obstacles, but this is one of the major things that needs to be addressed before a LiveDVD effort becomes very appealing (a LiveDVD which needs to run bind and DHCP to work well is frankly a scary idea.)

47
Users / Re: USB-UIRT - How many av devices?
« on: March 20, 2008, 05:15:19 pm »
By default the USB-UIRT can control at least one dual-head low power (stick on) emitter using the IR port (+ use the internal IR emitter(s)).

With and IR distribution amplifier using the IR port it can control as many as the distribution amp can support...

48
Users / Re: While upgrading from 710beta3 to 710 beta4
« on: March 20, 2008, 05:11:14 pm »
I've also replied via a private message.

I don't know the answer in your particular case, but I would like to look around on your machine (see private message).

In general we will test all install & upgrade paths for the final release, and doing a clean install with a beta after reporting the problem on the forums is your best bet (and was your only option for betas 1 & 2).

49
Developers / Re: This Community will Fail and LMCE will be forgotten.
« on: March 20, 2008, 05:04:37 pm »
I have to agree with Orionsune.  I have been using LMCE for a couple of months now and mostly lurking on the forums in the little free time i have, trying to learn as i go.  During that time I have to say i have come across more that enough negativitly, hostility and plain rudeness directed at different individuals to make me personally question how this project is being run and where its going.

The negativity is unfortunate. We need to work on that. The same problem plagued MythTV when that project was young. We have for the most part addressed the problem there. But it was something that took time, we needed to set make an effort to be civil and enforce the edict, "if you don't have anything good to say in response to a question, say nothing at all."

I get the impression of a clique running things that doesn’t take too well to criticism and has no real vision for the product besides their own narrow interests.  I can understand that during product development we all like to add the things we think are cool but if you want to make a product a success you have to think what does the typical user want and i dont really think too much consideration is given to this.

Look I have a hard skin to people calling me "douche pickle" and other unmentionable criticism. But this is a hard skin formed by many years in the OSS community as a contributor. We are a young project, with a number people who are new to OSS contributing. It can be a shock the first time you've poured your heart out spending nights away from your family to contribute something to the world at large only to be greeted with death threats in private and insults in public. As the project matures there will be mentors for the new recruits who will help them make the adjustment.

As cool as some things might be such as the Mame wrapper, the mobile java client, has anyone given any thought to making this product compete as a media center first, its name is LinuxMediaCenter after all.
Yes very much so, but you also need to realize that unpaid volunteers will have their pet projects. They are in fact a very good way to get people involved and learn the API's that they need to understand in order to make the mundane improvements needed. They also help the developer blow off steam. This is important when you are dealing with people who work as professional programmers by day, an OSS project needs to balance the "Fun" aspects that keep developers involved and the "Work" aspects that keep the project going.

1. Lack of a photo slideshow facility
Interesting, we could just install the MythGallery plug-in by default and point it to the LMCE photo directories. If you can document what is needed to do this in the wiki, I can create the package fairly easily. I really never thought of this, I've never actually sat down and showed my family a slide-show.

2. Weak Media Structure
I don't really understand this, you are aware of tags right?

While all the extras that come with lmce such as the lighting controls, the orbiters etc are fantastic these two things are glaring omissions and present major barriers to the product entering the mainstream and competing for the media center space within any typical family environment considering their options.  Put on top of this the less than amicable nature of some individuals on these forums, the lack of any perceived steering group and weak documentation and I wouldn’t count on lmce being here in 24 months time.  I think that would be unfortunate as it has great potential, i personally now have a working setup with 3 MDs around the house and starting to look at lighting controls and security cameras.  But still as a media center i cant make it do the all of basic things that XMBC could do, or my 360 acting as extenders.
I'm certain LinuxMCE will be here in 24 months time.

I also have to point out that the find by Orionsune in regards to MythTV hanging all the time due to what we now know was logging issues should be seen reflected upon by those  in charge of this product.  I mean the amount of posts highlighting this and similar problems that went ignored demonstrates something is wrong here.

Heh, the bug that Orionsume found had only been manifest for a few days when you found it. I've made about a dozen stability fixes to MythTV in the last few months, including the major one that made LMCE's MythTV less stable than other distro's using MythTV. The "-v all" for MythTV debugging only became crashing after I removed a patch from the earlier MythTV packages that completely disabled MythTV logging. I had removed this because the problems with installing MythTV on MD's were not possible to debug with debugging disabled for the backend. The excessive frontend logging was not apparent to me because I was looking at the backend log for the MD problem, and because my computer had no problem handling the excessive logging. Once Orionsume found the bug, I had committed the fix within a few days. That is how things are supposed to work. Orionsume like all of us is supposed to find and if possible find a fix for the bugs he sees. This is why betas are released, so we can all find and fix bugs, not just some clique of developers up in the sky somewhere.

I really dont mean to over criticise but something really doest seem right with how the product is managed.  And i do appreciate the work that has gone into making this product what it is but still some things do need to be said.  I hope they can be taken as constructive as that is my intent but i suspect some may view them in a different light.

Thanks Andy, I totally understand your concerns (well except for the media organization stuff), I wish I had more time and we had more contributors to address them my own countless concerns with LinuxMCE.

And on that note, I would love it if you could volunteer to work on something. :)

I like your slide show idea, perhaps you can investigate MythTV and other slideshow programs for Kubuntu and write up a report in the wiki? If you would like I can also walk you through the steps needed to implement your ideas in something that will be installed by default and automatically configured by LinuxMCE, or that scares you, you can wait for me to take your wiki and express it in packaging scripts.

50
Developers / Re: Any chance to use Mythphone as video phone on MD ?
« on: March 18, 2008, 01:45:51 am »
MythPhone was unmaintained in MythTV 0.19, 0.20 and 0.21 and grew a bit of cruft.

Shane S. of MythTV has recently begun submitting patches to get this plug-in running well again.

Of course, the problem is that we would either need to keep MythFrontend running, possibly on a different virtual desktop than the Orbiter, or we would need to create a MythPhone DCE Device specifically for MythPhone. Neither is impossible but someone would need to spend some time implementing this and be willing to maintain the code.

If anyone is up to the task, please contact me by e-mail and I'll help get you started.

51
Users / Re: Why I left LinuxMCE for MythBuntu
« on: March 18, 2008, 01:06:28 am »
I would just like to say that the LinuxMCE developers have no problem with Ubuntu or Mythbuntu for that matter. Paul made a very good choice when he decided on kubuntu as the base.

We are working on hardware and driver problems for the 710 release. The two NIC requirement for simple setup will stay for the foreseeable future since much of what LinuxMCE does which Mythbuntu can not depends on having an internal and external network; yes it is possible to use one NIC, but this is by no means a simple thing to accomplish.

I hope you will give LinuxMCE another try in the future. I think we're doing well for a young distro and 710 and 804 are looking better by the day. But of course -- I am a little biased.

52
Developers / Re: Adding new Device Templates
« on: March 18, 2008, 12:17:57 am »
We did a few test commits last week. It didn't go so well this first time around, broke the build.

We will be doing some more commits this week and once the proper procedure is clearly understood we'll put together some documentation.

53
Developers / Re: Brazil HDTV capture cards
« on: March 11, 2008, 11:46:16 pm »
Brazil is using ISDB, the Japanese HDTV standard. You will need Japanese capture cards.

This is the only card I know about:
   http://www.computermodules.com/broadcast/ISDBT-Modulators.shtml

They have a little Tux icon on their webpage, so I assume they have Linux DVB drivers. However they also don't list a price and don't appear to sell this card in Brazil... Also I don't know of anyone that has used this card with MythTV or VDR, the two DVR applications that LinuxMCE 710 beta 4 supports. Theoretically the data coming from the card is plain old MPEG-2, but these applications may require some tweaking to the tuning code before they will work with this card.

PS I know of no ISDB-S or ISDB-C cards, but they may exist and I'm just not aware of them.

54
Users / Re: Which version of MythTV is bundled in 0710b4 ?
« on: March 07, 2008, 05:14:33 pm »
It's a custom build, it contains the latest 0.20-release-fixes + a segfault preventing patch + keyremapping patch to avoid key collissions on F6-F8 + several patches from the ubuntu folks to allow it to work with the ubuntu file system layout and with the ivtv drivers in the kernel we're using + some patched to avoid nagging about missing ivtv ioctl (which are absent in the ivtv used by ubuntu).

As far as working with other non-LMCE MythTV installations on the same network, it is network and DB compatible with 0.20.1, 0.20.2 and pretty much all packaged 0.20.x versions (there was a bug in the initial 0.20.0 release, that required a network protocol change, but pretty much all major distros released a 0.20.0 with the fix).

55
colin, orion: I've fixed the "-v all" in the source. This wasn't causing problems for me, but my lowliest computer running LMCE is an AMD64 dual core 4200+. "-v all" produces debugging for every audio buffer drained, every network event, every db change, everything! It's a crazy option to use in a production build. Good catch.

56
Developers / Re: 710 Release TODO
« on: February 27, 2008, 04:37:25 am »
I don't see VDR in your show stopper list. Does this mean VDR is now in working and usable conditions? Or is VDR falling off 0710?

It's more or less working. But there won't be a lot of extra functionality VDR plugins this time around.. VDR==DVB for now.

57
Developers / Re: minutes from the conference.
« on: February 27, 2008, 12:05:58 am »
Ok, so I'll just write this off the cuff:

There are two proposals:
A) If Pluto is going to use UI3 for their own commercial stuff
B) If Pluto is not going to use UI3 for their own stuff

For the core of the backend rendering engine it doesn't matter which is the case. The idea is to leverage libplasma. It will be getting hooks for SWF (aka Flash) applets and already has a rich applet architecture. All it needs is some hooks and color conversion functions so it can be used efficiently with applications such as Xine, MythTV & VDR.

Where A or B starts to matter is with the API for creating the UI on top of libplasma. In scenario A, Pluto would need to write it's own XML reader/writer, in scenario B we would appropriate the MythTV XML reading code.

Where A or B really matters is in the UI creation tool. If Pluto uses UI3 for their own stuff, they can justify donating the labor of a half dozen programmers, the tool itself would not be GPL, but would probably be a web page + plugin that could handle the libplasma rendering. With some kind of agreement between Pluto + the LinuxMCE Foundation so that if Pluto or it's corporate heirs stop providing the web page the foundation could take over that duty and release the code so that others could as well. If Pluto does not use UI3 for their own stuff, they can not justify putting a number of full time programmers on the task but could provide some limited assistance.

I can't speak for Pluto here, so I can't tell you yet which option they want to pursue. My understanding is that they are in negotiations with some 3rd parties and how those turn out will determine how on board they will be.

As for the other issues, I've been talking to Pluto about their level of openness for years. And much more so since I've taken on a significant role with LinuxMCE. I think they are moving in the right direction now, but mostly because they're now convinced that LinuxMCE can be a greater benefit to them than a liability. But make no mistake they are a for-profit and they will help us only so far as it helps them as well. Don't expect them to be handing out any candy. If you want something done you need to do it yourself.

Anyway for the minutes, I didn't keep the best notes since they were only for my own use:

Riccardo           -- KDE libplasma
Daniel K            -- LinuxMCE/MythTV
Isaac R              -- MythTV
Aaron                -- Pluto
Demian(1audio) -- LinuxMCE/?Pluto connection?
Rob Savoy          -- GNASH
Matthew             -- LinuxMCE by webchat
D. Damron         -- LinuxMCE by webchat
Tschak               -- LinuxMCE by webchat

There were more, but I just wrote down someone's name if they said something I wanted to follow up on, I wasn't making notes of the meeting for anyone but myself.

Brainstorming:

Scripting Languages:
  qtscript -- interpreted
    This was suggested by Riccardo, it is very similar to ECMAscript, but has hooks for C++ programs
  javascript -- interpreted
    This was suggested before the meeting by Jason Tackaberry of freevo and brought up by Daniel
  "eclipse" javasript
    This was suggested for the C++ bindings
  KDE Kross
    This was suggested by Riccardo
  ECMAscript -- interpreted
    Brought up by Riccardo and Rob Savoy as a better (more standard) alternative to javascript
  C++ -- compiled
    Suggested by Aaron since it would allow you to write things like colour conversions in the UI.
    But Rob Savoy (who did compiler work in the past as Cygwin) brought up how much work it would
    be to make gcc work in an interactive environment. Aaron later dropped this as unworkable.

Issac said it didn't matter which scripting language was chosen, most designers would just cut-n-paste other people's code snippets. And the few that actually wrote bits of code would hammer away at whichever scripting language was chosen until they got it working. All the proposed scripting languages have about the same learning curve and if not javascript are almost identical to it for someone with a web scripting background or no programming experience at all.

After some discussion it was agreed that this didn't matter so much it mattered that the UI was scriptable; whichever of these near identical scripting languages are easiest to fit into the rest of the whole should be used.

GUI definition language:
  XML was suggested by both Daniel, Issac and Aaron. This is the basis of the the new UI being written for MythTV (MythUI).
  SWF was suggested by Rob Savoy. This is the basis of GNASH UIs
  Raw libplasma programming was suggested by Riccardo
  C++ binary was suggested by Aaron

There was much discussion on this, which mostly went in circles. The C++ binary suggestion was made by Aaron and thought of as a way to enforce GPL licensing in addition to producing faster code. However, after some thought he felt this wouldn't produce a stronger GPL tie-in than simply linking to GPL libraries; and he was convinced by the other participants that this code didn't have to be fast as it would mostly just be calling libplasma to do all the heavy lifting. Matthew and Aaron had a bit of an argument on the licensing aspect but we all decided to lay that aside after about an hour and move on to other issues.

SWF was not liked by anyone other than Rob and Matthew because it would require a whole new GUI creator that wrote out in a GNASH only format and used a number of tricks to prevent Adobe's Flash tool from destroying the files. Both Rob and Matthew felt these issues could be overcome. Ajax Animator and other tools were suggested as a starting point. However the rest of the meeting participants felt that it would be almost as difficult to turn these tools into full featured design tools as starting from scratch. Before a complete impasse was reached, Riccardo brought up surprisingly good news. The libplasma were already planning an integrated GNASH player as plasmoid (plasma applet) so gadgets could be designed in SWF and incorporated into any libplasma based UI.

Raw libplasma programming was suggested by Riccardo, but roundly rejected by everyone else. His contention was that designers would either program like him and not fear C++ or not program at all. He also felt that a UI designer was not needed, but instead a programmer should be paired with each designer and work in tandem. The argument against this was basically summed up by, "This is what we're all already doing, we want something better."

XML was in the end the container format to please all, it can contain SVG and PNG graphics. It can contain scripts that work on nodes in the XML tree, and it can contain plasmoids including whole SWF ones. Basing it on the MythTV one might be appropriate, but this wasn't decided on.

Graphics formats:
Not much contention on this issue, SVG as primary format, followed by PNG.

Design Tool:
  Inkscape for SVGs
  Eclipse
  qtdesigner was brought up but considered inappropriate without much discussion

None of these are by themselves usable as a UI3 user interface designer. Except for Riccardo, all thought that this was the big missing component that would allow the rest to work. Aaron said that if Pluto could make a business case for it they could fund the development of this component. With Pluto development funding Inkscape would still be used for creating SVG's but the rest would all be handled in the design tool. A suggestion made by a few people was that if Pluto couldn't fund the UI3 design tool for any reason, it might be possible to either hack Eclipse or Inkscape to add on the missing components. Inkscape is a better starting point wrt to UI3, but Eclipse has a powerful plug-in architecture, that might even allow Inkscape to be treated as a plug-in.

TODOs:

After the brainstorming session. We moved on to what needed to be done to get this implemented.

The backend was considered something that just needed a point man -- but the expertise for this was contained in the room.

None of the people in the room were knew how to design a tool for UI designers, but Thomas and Matthew on web chat had some ideas.

What is needed is
  a mock-up of screens
  click count for common actions
  pick target platforms (Ubuntu Linux, Fedora Linux, Windows Vista, OSX Leopard, etc)
  pick lead platform from among target platforms (Ubuntu Linux?)

Mock-ups of the UIs to be generated (just document the following):
  TiVo, FrontRow, PS3, LinuxMCE, WindowsMCE, MythTV

Navigation Mockup (in Flash or something like it)

We need a flash designer to generate this type of requirements document.

Thomas + Matthew will contact their UI experts, Pluto willing to pay for mock-up work.

58
Developers / Re: 710 Release TODO
« on: February 26, 2008, 10:11:51 pm »
Daniel--

Do you mean Pete's Insteon driver?  I know I haven't done that much, but I'm going to claim credit for what I did do!  ;D

Yes, yes I do :)

This is a pretty basic driver, especially compared to Dan's PLM driver, but It was a first cut and does provide basic USB-PLC functionality.  So far I think I'm the only one that has tested this, and Pluto is still trying (somewhat) to resolve a start-up issue with it.  I really think this should be tested by at least one person other than me before we call it ready for 0710 and put it out.

The preferred path I think at this point would be to recommend the Insteon PLM, a newer device with a better interface and a much more complete (thanks to Dan) driver. With the PNP detect script, it should be functionally comparible with the USB device for the end user.

As for syncing Dan's driver (currently in Hari's DB, I believe) to the release (pluto's server), have you guys found a way to do that?  I know Kirill definitely had problems doing that with some of my templates that I had checked into Hari's server and then tried to put in the Pluto server.


I've been busy with work lately, but I have been trying to get a ZCU101 for testing, but I haven't been able to yet.  It sounds like Hari's got the USB driver working.  I'm pretty familiar with the previous Zwave implementation, so if tweaks are needed for the new device, I can help work out those issues.

Shoot, I just got a ZCU101 for testing the ZWave stuff, I could have gotten one for you too. I sent ddamron the Insteon device you sent me, so that he can look at that stuff.

59
kir is probably right on all those..

Heh, a "double word" being 32 bits also indicates that original the programmer was probably a Windows programmer :)

A "word" is the basic unit of the processors, usually 64 or 128 bits on modern processors, and Linux originally only supported processors with a 32-bit or larger word size. So on a modern computer double word should really be at least 128 bits. :)

PS to create a real double word in most C and C++ compilers you declare it as a "long long".

60
Developers / 710 Release TODO
« on: February 25, 2008, 11:37:07 pm »
Just so people know why 710 isn't here yet. Here are the major TODO's, the "*" ones are ones I really want to have fixed before 710, and the "+" are ones I'd like to fix since the release will be delayed anyway for the "*" ones.

The remaining TODO's are:
  VIA support is pretty lame at the moment:
    * Cursor leaves dandruff (fix is to enable SWCursor in xorg.conf, need to make default)
    * MythTV menu text not always drawn.
       (Maybe switching from 24 bit to 16 bit fb helps?)
       (If not, maybe MythTV OpenGL menu drawing should be enabled?)
  nVidia 7150 + and some 6150 systems have high cpu problem
    * Causes high Xorg usage with MythTV + Xine, unless V-Sync disabled
       (Worst case, we can detect high CPU usage and enable V-Sync hack.)
  Z-Wave
    * We need US (120v) USB support, basically ZCU101
    * I think we need to make sure Hari's stuff is all on the DVD/CD +
       working for HA22 in Europe
    + It would be nice to support ZCU201 in addition to HA22
       (probably a freebe as part of getting ZCU101 working.)
  Insteon
    + We have Paul's driver, which is fine; but it would be nice to
        have Dan Damron's stuff with the plug-n-play USB Insteon device.

PS New things may be added to this as testing reveals more problems, but as you can see the remaining issues seem to be mostly related to specific hardware and not overall system issues. This also doesn't list problems with beta 3 which have been fixed in SVN already..

Pages: 1 2 3 [4] 5 6 ... 11