Messages

@toppot: just hot air from you, as I did expect..

Good relevant input. Really pointing me in the proper direction with regards to which design choices to make in this early stages... And obviously, something that has been "broken"/stale since 2004 can't take more than 10 days to solve...

Nice also to see the detailed roadmap and milestones plan in the same link... Meaning everybody now knows what we are working towards, and have a proper sense on the urgency towards relevant dependencies..

Super :-)

Given the deluge of responses I'll guess not

Might take a punt on one anyway - although I don't like the fact it has no dedicated media buttons.

-Coley.

The mouse+keyboard part will work OOB... It could be, that some mapping of keys to simulate the missing media buttons could be worthwhile. Or you could consider something like http://www.amazon.com/gp/product/B006OW1J1M/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=B006OW1J1M&linkCode=as2&tag=squid09a-20
That has media buttons. Honestly, I believe the biggest factor for if it will be a success is if the quality of movement is good.. If it is quick and precise you will enjoy it. If it is slow and/or unprecise you are going to hate it until it is shelved...

Would read some reviews, and rest assured - USB mouse and keyboard part will work without drivers...

-Toppot

P.S. Please let us know how it goes?

Our current development is happening for 1204 in svn/trunk.

Never got any input in to if anybody is working on TV in 1204... But looking around in svn revealed a bit for me...

There's no trace of Myth (neither in branches 1004 or trunk) - it does exist in 810.. odd..
In /external I can find "VDR.Oct-10-2005/"... Will consider that not to be under heavy development??? (The current version of VDR is 2.0.2, but it is still from the design concept meant to be a stand alone application, and only support the server-client needs we have via plugins - to the best of my knowledge).

So input on what's going on, if anything, would be great...

-Toppot

As an alternative to disabling functionality (that you might need later) I would suggest separating the networks, so that LMCEs DHCP only controls the relevant part of the network, but the DNLA TV and Playon is kept on the "outside"...

(let me try to draw a map, perhaps that's easier)

Internet --- Gateway (local router) ---- Local net (outside LMCE) ---- LMCE Core -------------------- Local LMCE managed net
            Example IP configuration:
All IPs                  /102.168.1.1               192.168.1.x                       192.168.1.200/192.168.80.1          192.168.80.x
                           Router                     DNLA TV (192.168.1.10)                                                      MD 1 (192.168.80.40)
                                                         Playon (192.168.1.20)                                                         MD 2 (192.168.80.41)
                                                         SAN (192.168.1.2)                                                              Weborbiter (192.168.80.42)

You would need to enable LMCE autodiscovery to "see" the SAN share - or alternatively put the SAN inside the LMCE "domain" (i.e. 192.168.80.??) and then forward relevant ports/services enabling the local-outside units to access the SAN...

And then be aware of where you place other units (PCs, iPads, Printers, etc.) - some forwarding/mapping of ports could be needed when units are on different local nets.. But a few simple rules should cater for all

-Toppot

IThe goal for a new TV media provider must be to be better than the existing ones. This means, setup must be possible from Sarah, timer screens must exist, and EPG screens must exist.

Actually, to venture in to this, my personal goals must be a tad more ambitious. For me the experience from daily usage is by factor 2000 more important than ease of setup etc... That is exactly my biggest problem with how TV is working currently. Easy to setup (not even that for 95% of users), distress to use (probably true for 80%+ of users)... My order of priority:

1. Flawless LiveTV viewing. (I really mean flawless!!!! Like you would have on a highend STB). Subtitles, audio language and audio track selection should "just work".
2. Intergration of EPG - and timer management (including repeated and series recording).
3. Playback of recording (this should work OOB, but please see #6). Also the pre-selection of Subs and audio should persist.
---------- Cut line, until we are here it should never be released!!! --------------
4. Flawless Timeshift (probably meaning that LiveTV will be through VLC).
5. Integration of TvH management in the LMCE web-admin
6. Commercial detection (using Comskip for Linux, and ensuring player will use cutlist - I know Mplayer support this, but not if it is enabled - not sure about VLC). The design question this opens is, should we just dump the recordings for LMCE to figure out, or use the HTSP transport from TvH... I still await some feedback to earlier questions before I can form my opinion here.. But I lean towards letting LMCE do the work, granted cutlist will be considered either through setting or as standard..
7. Ease of setup through the Sarah-Wizard
8. Integration of Comskip management in the LMCE web-admin
..
..
10012. Transcoding of LiveTV for playback on Orbiters (personally I believe playback on an Orbiter is misunderstood... I prefer splitting between Orbiters, and Tablet/Phone MDs with on-screen orbiter, although they should be a special case of the MD concept, since they will be a frontend application rather than a unit controlled by the Core)
..
..
15003. Automatic installation of new TV adapters, including transponder/channel search - EPG mapping etc. etc... I don't see the need to enter a separate web-admin and controlling TvH that way as a big issue, but for the ultimate Plug&Play experience I will keep it on the list
..

But please - I could have some priorities skewed here - provide your input to how priorities should be... The more opinions I get here, the better..

-Toppot

Much appreciated feedback!

Things that need to be done for another media provider:

* Create a plugin for it, which provides data to LinuxMCEs data grid providers

Check - part of 1. priority (needed to get anything working)

** Create the datagrid provider for EPG

Same as above..

** Create the datagrid provider for recordings (probably not needed when you directly store in the video subdirs)

Right - but would you recommend to just dump the recordings and let LMCE discover them, or would you (from design policies) recommend to add them directly in the DB??

** Create the datagrid provider for timer

Should be pure copy paste - and part of 1. priority

* Create a player which talks to the plugin, and controls the frontend for the media provider.

Some work needs to be done here - as far as I remember it is already possible to use VLC for media playback? Would you recommend sticking to a generic implementation allowing for selection between Xine and VLC (or mplayer), thus limiting functionality (timeshift)? Or would it be an OK approach to require VLC as the frontend player?
Actually not sure what you mean by "create a player"... I should just ensure that the controls from the plugin can work with something lightweight like VLC or another off the shelve player, right?

* Create frontend screens for media playback control, including pages to add/modify/delete timers and view EPG data.

Copy paste from existing frontend screens, unless I  have completely misses the point of the modular design??? It is via the plugin that pressing the button ensures that the proper thing will happen in the router??? Or??

* Create setup pages for the 'Sarah Wizard' to setup devices and channel configuration

Really??? The current implementation of this is almost never plug&play, unless you live in US, and subscribe to one of the supported XMLTV providers... Raise of hands: I there a single user of TV in LMCE that hasn't been using either the backend setup of Myth or VDR??? I doubt so - this is clearly prio 5... But more important - it should be possible to choose TvH/VLC as the TV provider both during setup and in the webinterface..

You can probably use the VDR and VDRPlugin codes quite verbatim as a good starting point.

I also plan to do so... Only caveat here is, that I actually never got a really working setup out of neither VDR nor Myth... But I have seen moving images (brief, oftens pixelated - and crashing after a short while, usually before the lag from the slow Myth channel change was over 

I actually use VDR within LinuxMCE, and agree that the MythTV integration is much tighter.

Are you satisfied with the current state of the VDR implementation? Or put in other words, in no way trying to be "smart": Does it work well, or is it (more or less) a daily source of frustration? Feel free to elaborate, I am not venturing in to this, unless I have a strong feeling that I can create an improvement...

Our current development is happening for 1204 in svn/trunk.

Then I will work from there...
One question remains: Are anybody else working on TV atm. ?? And should there be more than one backend available (remembering how Thom aired frustration over the Myth team, and how some of their design decisions makes our lives difficult - he used the words: create a new solution for TV altogether)??

In my book, the virtue of LMCE is NOT developing things from scratch - it is integrating existing solutions i an extremely clever way... Unless there is nothing that can solve a problem for us, then we can be forced to develop..

-Toppot

Fight? Really? is that what you all think of me? I'm disgusted.

-Thom

Glad I was able to provoke a bit....
This is most likely NOT how "all of us" think of you... Actually, what you got from my post is not even how I think of you. The provocation was intended, but believe me when I openly state that I am a very big fan of you, and deeply impressed with all the hard work you (and others, none mentioned, none forgot – but this whole project lives and dies with you 5-7 die hards that have been putting an incredible effort in to the system) have lend to this project over the years..

edited:

I've been busting my ass on this project, since day one, coding, trying to make things work, making tutorials, HOSTING CONFERENCED WORKSHOPS, JUST SO MOTIVATED PEOPLE WOULD ACTUALLY TRY TO CONTRIBUTE!

If this is how I am seen, and treated, then I have nothing more for all of you users, all whiny, waaah waaah WAAAH!

Would be a loss for all..

This system is modular! IF YOU WANT A FEATURE, ADD IT! ASK ME HOW THE SYSTEM WORKS! PARTICIPATE! I WILL ALWAYS TEACH! ASK ANYONE WHO HAS ACTUALLY CONTRIBUTED ANYTHING TO THIS PROJECT, AND THEY WILL TELL YOU THE SAME!

hmm, over the years I could probably find a soul or 2 being put off by harsh comments (because they see the world slightly different than you) - but you are obviously right that if you only look a those that managed to get code folded in to the project, they will all agree that you are most helpful.

toppot, it is taking every bit of my tongue right now to keep from completely unloading on you for your last statement, it is uncalled for, and I am _DEEPLY_ offended.

-Thom

You shouldn't be offended: Try reading again... When I state "option 3. will probably newer be done, since Thom is quite happy with MythTV..." all I am really saying is, that I recognize the fact that you carry a tremendous load in this project, and if you don't do it - it will most likely never be done, simple as that!

That said #####################################################################################################
###########################################################################################################
##################################### CENSORED ##############################################################
###########################################################################################################
Long piece elaborating on the way this project work with references to historic threads ending in utter flame wars - I censored this, since this is the last I desire to accomplish ############################################################################################################
############################################################################################################
############################################################################################################
#########################

To get back on track!
Even with a modular system like LMCE, sometimes choices becomes exclusive - either for technical reasons or due to the desire we all should have NOT to fork or diverge the effort towards a stable and usable system. In some of these debates you have been ... Lets just say firm  in some of these situations. On many occasions with the sound reasoning behind that you are one of the few pillars that will continue working on the system, meaning a choice that is favoring a developer that is "in and out" in 6 months, or half a release cycle, could potentially be harmful in the long run... But sometimes good ideas have been shot down, even if they actually ARE good...

So to be very concrete:

1. Apologies if I offended you (or any other of you guys doing so much for the community). That was unintentional!!
2. The provocation was intentional. Now that I have your ears:
2.a.: Could you give some advice to get descrambling (legally - obviously) working under Myth? We are not all living in US, so some of us rely on subscriptions to scrambled DVB signals for TV... (OK, ignore this - it was just another tease...)
2.b.: You actually managed to get me provoked. I would like to integrate the TvHeadend backend server in to LMCE. I am willing to put the programming effort in to this. It is, conceptually, dead easy. The package must be compiled for 10.04. The VLC HTSP plugin compiled for 10.04. The controls should be controlled via the VLC console - all should be small changes/updates to the controls for VDR, right? (this actually support absolute positioning in playback of live TV very nicely - pulling out "get_length" and using "seek X" to position...
All I would need to do further is to enable hooks to grab the EPG data from TvH in to LMCE - and then code a bit to generate proper commands to schedule recordings and control VLC...

Can you point me a bit in the right direction?? And how do you feel about adding this "fork"/module?? Are you all for catering for us Europeans, or would you prefer sticking to Myth (and the somewhat stale VDR integration)? EDIT: Just read i bit in old threads.. I realized that you Thom actually do not favor Myth.. Just that you would start working on an alternative route. Has some of this work started?? If not, then I volunteer to this. My suggestion is not to take an integrated system like Myth and bolt that on to LMCE (heavy and slow), nor taking a single-system like VDR and try to force it to be server-client like... Rather: a backend that wants to be a backend (like TvH) and a frontend that aims to be exactly that... could be VLC (du to the HTSP integration) or Xine, Mplayer - whatever...

I am a strong believer in adhering to the design concept of the framework - meaning it should be possible to use this independent of how a implementation is made, or how (orbiters etc.) it is controlled..

With sincere hopes that I didn't ruin your day - but also with hopes for an open debate on this specific topic. Luckily I CAN code - I realize that otherwise you are not very welcome to make suggestions in this project. Contribution is in my book not just getting lines of code in the repo - but there we just differ...

BR

-Toppot

Yesterday I started playing with a backend I found in the XBMC forums.

It's only a 2MB .deb file and runs happily on my 8.10 testserver.

For me it does what VDR and MythTV never made possible... I never get them patched correctly and in the end I just run in to dependency issues. All I want is to see the channels I pay for on all my MD's.

It has a webgui for setting up, and it's just way to easy to set up... I started thinking "is this a joke?".

With only 2MB, it is able to detect my DVB card (i had installed S2API drivers), and it was identified as a DVB-C card and I could select cable providers. I selected Norway, Canal Digital. And it added a few transponders.  It did not have all (like any other software I have seen) but then things started happening in the monitoring window. It was scanning the transponders automatically, auto detecting new transponders and after 1 minute or so it had a complete list of channels and transponders?!?

On the same page there is a Probe button to add channels to the frontends, and when pressing that, it tested every channel for open or encrypted and added only those channels which where open to the frontends.

It even has a integrated Card Client, and I added my Dreambox, which is where my subscription card is located. Now I did a new probe, and it added also the channels I had on that subscription card

The EPG started filling up automatically on all channels and I could record, shows.

All this was done in the webgui. Recordings are done in MKV and play on LinuxMCE.
It even supports recording of my HD channels.

So can this be uses for LinuxMCE? The backend seems complete, the webgui is done, easy to install, no patching, works out of the box... But what about the MD's? Well, it's a backend that streams to any frontend...

It uses HTSP:
http://trac.lonelycoder.com/hts/wiki/htsp

Since there is no support for that on LinuxMCE I have tested it on XBMC and I must say I'm impressed! It works
Just added a URL and that was it, I could browse channels and start them. Pause also work.
Since XBMC has VDPAU support the streams where not using much CPU.
On SD channels there was no difference when VDPAU was off, but HD channels where unwatchable without VDPAU.

The backend is called TVHEADEND and you can find it here:
http://www.lonelycoder.com/hts/

The online manual is good and you find it here:
http://www.lonelycoder.com/hts/tvheadend/docs/2_1/index.html

Lonelycoder also makes a frontend, but I did not like that much.

Does anyone know it the HTSP streams can be added easily to LinuxMCE?

It is quite sad this got so old, and nobody responded... So many things are possible with LMCE, few fundamental changes (like the ones you suggest) are "easy", but to elaborate a bit further this is still worth considering - and i would like to outline 3 possible ways to move forward:

1. TvHeadend will stream via http. You can play that with anything, and have it leaving the recordings in a share that LMCE can access is something many users does already - for reasons I will elaborate a bot on below.. Further, you can easily watch liveTV through a http link. Just create a scenario that launches VLC or Xine or whatever... You would then need 1 scenario per channel.. Not optimal, but in some scenarios doable..

2. You could also use TvHeadend, and compile to HTSP addon to VLC - that would allow you to control the live streams from VLC, and having your LMCE remote mapping the proper keys.. Channel lists, channel groups are nicely integrated - EPG not so..

3. The whole project is open source - deep integration is very possible, both for retrieving the EPG, controlling the playback (if LMCE controls the EPG/Channel data, then HTTP is no setback compared to the HTSP protocol - unless the network is VERY congested), thus no work needs to be done with regards to interpreting HTSP... It is just a matter of dynamically generating an URL for Xine or VLC.. and BOOM, playback is controlled

1. and 2. can easily be done by everybody... option 3. will probably newer be done, since Thom is quite happy with MythTV... It is sad, since especially for Europeans TvH is a MUCH better alternative. I would even argue that in the long run it would be beneficial for LMCE to include support for TvH for 3 reasons:
a. It is lightweight - just like VDR
b. Is it a backend project, that for the sake of completeness also has it own frontend.. But the interest clearly lies with developing the backend. And since LMCE should always be the frontend, this is exactly what we should desire.
c. It works! Also with completely legal descrambling... (and yes I am aware of all the potential issues regarding descrambling, primarily that illegal descrambling is almost easier to get working than legal descrambling. But I don't care, I am not the police - neither is Thom, and his point of view is actually quite unamerican...

Come to think of it... Deep integration is actually just a matter of ripping the EPG info from TvHeadend - It stores it in memory, but present it both through HTSP and via its webinterface - meaning a crude solution could be to just grab it from the webif and import it in to LMCEs database.. And then on top of that, making sure that for live TV LMCE can generate an url that is properly formatted... This is actually not that hard, perhaps I should do it...

I probably won't - simply don't have the time atm., and neither the urge.. I have newer been close to using LMCE for live TV. Zapping times alone (MythTV) has always been the spoiler... And Stability in Myth (the version used in LMCE) is actually also poor. On top of that comes the poor descrambling support..). I newer got anything useful out of VDR, that is so poorly integrated that I would newer recommend it... And then I suddenly remember: Timeshift is only supported via HTSP.... And I am not going back to not having timeshift again... And I don't believe it is "just" playing a HTSP url via VLC (with the HTSP plugin compiled for it) is all that is needed, so I probably won't do it.... (just fiddled with VLC - it actually IS that easy to use HTSP via the console...)

But perhaps somebody else will fight Thom for this.. I will gladly support with DVB specific info if needed, and/or testing...

Just wanted to add my 2 cents - since this poppes up every now & then...

You should go for 2 networks, this simplifies everything. But please remember (and this goes for all, see example like this thread http://forum.linuxmce.org/index.php/topic,13316.0.html):

2 networks can easily and happily work on 1 physical network, and 1 network card can just as easily have 2 IP addresses! So in this concrete example:

Set the IP of the router to 10.0.0.1 (netmask 255.255.255.0) - disable DCHP
Set external ip on your core to 10.0.0.2 (on card eth0), gateway 10.0.0.1
Set internal ip on core to 192.168.0.1 on card eth0, which is referred to as eth0.0...

From a logical point of view you have 2 networks, and every issue with regards to the internal workings of LMCE is unaffected. Any machine in your network will never become aware of the fact that you are running 2 logical networks in the same physical wires.. It is completely transparent, except for instances that relies on broadcasts - but just concern yourself with letting that run in the 192.168 network - and it will if you just let DHCP run from the core, and nowhere else..

So even if you mixed up netmask with logical network topology, your idea works - and the only real drawback in your suggestion is the overhead that comes from enlarging the subnet.. So stick with class C subnets (255.255.255.0). Your LMCE DHCP server will route the traffic anyway..

-TOP

ok, this question is moot for me now, I need a new wifi-ap anyway, and then I'll just go for the recommended setup.

Thanks for the input anyway.

Best regards
Daniel

Just a suggestion here (actually 2):

Could you perhaps for the sake of overview etc. delete a VERY problematic ISO like LMCE-1004-20120508033925950.iso? Its only if in a day or 2 somebody find a specific problem with the latest, and you have to advise not to use it - somebody could perhaps overlook this thread and then download an image that is REALLY problematic... It's fine to have the old ISOs available, I remember back in the 810 days when sometimes a beta 3 versions old would be the best at a given time, but if a snapshot is bound to be defect, then lets remove it..

And secondly: I am the biggest fan of rsync - how about having the latest ISO twice on the iptp.org server. One should be called "LMCE-1004-20120509195625955.iso" (or whatever), and then the other one could be "LMCE-1004-latest_pre-beta.iso" - and all people should do is zsync that file, and never have to worry  (since you would be the one overwriting the latest - with the latest

-Tony (who's is only downloading the DVD iso because his setup really F***ed when disabling Myth and enabling VDR - and decided to test this iso)

It's finished baking.

For those of you with older iso's, what I would do if I were you, is try and take advantage of the new zsync's.

Just rename your current image to the new one, so for instance:

Code Select Expand

mv LMCE-1004-20120506204225945.iso LMCE-1004-20120509195625955.iso
sudo apt-get install zsync
zsync http://linuxmce.iptp.org/snapshots/LMCE-1004-20120509195625955.iso.zsync

and it will just download what is different between them

Hi all,

Not sure if this goes in to this thread or not...

What is the problem with Myth? Or perhaps a bit sharper: What's the problem with Myth under LMCE? since it appears that many (and many, and many) users are having a good and hassle free experience with dedicated Myth distros.

Is it the backend? Then I am going towards a dedicated myth backend, that the LMCE-Myth master backend can utilize (believe we are keeping to 0.23.1? Rigth?). Is it the frontend, then moving away from the current setup seems to be a very strong suggestion. Is it as stated below the communication between front and beckends, then a rethink would definitely be on top of the list!

Personally I have never got to a usable LMCE solution, solely because of the poor TV experience - and I am not limiting myself to Myth, since I **WANT** what LMCE potentially can deliver. So for the moment I am booting up the servers (physical and virtual) and MDs every now and then, see where it brings me.. But I feel there is still some way until I would consider taking the plunge and go "all-in" on LMCE..

I can easily follow why some (Thom and others) are having a quite hateful relation to Myth, but feature comparison wise are we not limiting ourselves too much by going the VDR way? For me comm-flagging and the advanced scheduling are VERY big Myth plusses. I would like (before offering myself to doing actual developing) to have the input from some of you with more experience with how TV CAN work. If Myth was stable, which platform would you choose, Myth or VDR?

I am all for (since 0.25 is tied with 12.04 already) going down that route, everything else seems to be like putting a Mickey Mouse patch on a leg torn of... 


-Tony

posde, I understand where you are coming from. My point being that from what I could determine from looking at the code( and I could be very wrong) currently MythTV Player communicates through a socket with mythfrontend to watch, change channels etc. The mythfrontend client communication is fairly unstable. This new api would allow an lmce md to communicate directly with the mythbackend even if it is through the DCEROUTER. We could basically eliminate the mythtv frontend altogether in favor of an lmce frontend.

Look here: http://wiki.linuxmce.org/index.php/GSD

This was a very simple search on the wiki... Since there is a wiki page with that title. Expect to do searches and learning yourself... If you do so, you will find that people are VERY willing to help.. If you sit back and expect everything to "fall in to the turban", then be prepared for the risk of some negativity or harsh answers...

-Tony

Hari,

Maybe a stupid question but what do you mean with GSD, I'm installing a Luxom installation, I'm interessed what you mean.
I like linux, but still have to learn, so I'm looking forward to your response.

My lone MD stopped booting a few days ago.  It still gets an IP, but when it comes to downloading the initrd and kernel, it bombs out.  Well, the actual order of fail is:

1. tries to download the kernel image that was built for it (can't)
2. then it moves on to the default (no go)
3. finally tries a local boot, but since there's no local install, the PXE boot stops.

I haven't done anything to the MD config itself.  I did however update the core.  Maybe the update did something.

I can see the tftp request on the core in /var/log/syslog.  The core answers properly (I think).  

What could be wrong?

Try looking at this thread http://forum.linuxmce.org/index.php/topic,7842.0.html

It could be either this exact error, or perhaps digging from here could lead you in the proper direction. I would assume from your description that it could be from this corrupted line in /tftpboot/pxeboot.cfg/01-<md-mac-address>

-Tony

thanks merkur2k Mobaxterm works awsome even gives me the folders on the left i love it this will do nicely o.O great little program. now i can sit comforably at my desk rather then knees in a server closet
and tackle my next problem getting this ati HDMI audio working -_-.

Dear friend... Especially since you are new to Linux I can only recommend flattening the learning curve whenever possible! Please get a Nvidia card... Please, take this bit of complexity out of the equation.

Rule #1 in LinuxMCE: Be patient...

Even quite seasoned Linux guys cram themselves in to a corner from "habit thinking" and sometimes over-complicate issues.. There's so much we can do with this system - but when we take the difficult choices we are sometimes struggling and wasting good time on stupid problems... Keep your eye on the ball, this is something we all should do. Solve the basics, and THEN add on.

Just my 2 cents.. And I am of course installing on a virtual server, and needing DVB cards... So I am not much smarter than anybody else, but I went there AFTER having a working install.

-Tony

I have been running 8.10 on a VMWare Server 2.0.3 for some time. Now I got a new physical server, and have installed VMWare ESXi 4.1 on this one.

I have now made a new Virtual Machine, and have installed 10.04. But I am in doubt:

When I "for fun" installed 10.04 in my VMWare Server, I installed VMWare tools prior to running CreateDiskless - now I did it after... It appears to be doing some compiling, and changing some of the files that are used when the diskless image is created - but VMWare tools are obviously not desired in physical MDs (and virtualized MDs can only be for testing)...

What is the better approach? And is VMWare tools even needed??

I am having some problems with USB passthrough. I can add the USB controller to my WM, and I can also add the USB devices. But nothing shows on the client, neither in lsusb or dmesg... (I figured that even if I could find no reference to USB in the VMWare tools docs it could be that it would solve it- but no).

I had USB passthrough working under WMWare Server - but actually not sure if it was on the LMCE machines or just some other virtual machines... The reason to change server is that the old one does not have USB 2.0, only 1.1 - and that is not fast enough for DVB-S tuners. These tuners can run on a MD, but my experience is that is the MD only has 1 gig of RAM, and half goes to graphics, then it is struggling to run a Myth backend (even with the master backend on the core).

I know others are using ESXi - are you successful with USB passthrough? And are you using 4.1 og 5.0?

EDIT: Newer mind the USB question - a reboot cured that  

Update: Now I got the Tevii S660 USB DVB-S2 tuner working   
So far I have been able to tune to the channels one 1 sat - I confused which cable went to which of my DISEqC switches (one committed, the other uncommitted) - and the very strange thing is that now both my sat box and Myth has them as committed... So perhaps it was a fluke that I finally got a transponder luck, but it was a quite persistent fluke... I could scan all transponder at that sat.

I recorded 1 show - but it seems to record full of artifacts (when I stream to a PC). Does anybody have ESXi experience with USB performance? Could I be in problems here, or should it be doable??

The next few days this server will be banned (since it was in the living room floor - and it is a 1U rack server that is NOISY)... But now the wife is back, so I suspect it needs to go in to the server room rack before further playing..


-Tony