[mythtv-users] MythWeb + myth-remote-control
I've been thinking a bit recently about a feature I mentioned a couple months ago, and it seems more implementable now. (Is MythWeb covered by the current feature freeze? :) The idea is to be able to browse recordings in MythWeb, but, if you clicked on the image in any given row, to have the frontend play it instead of having it streamed to the browser. This is handy in situations where you don't necessarily have a pre-established playlist, and would like to start the next recording on the fly while the previous one is still playing. (Useful for VJ'ing, for meetings in which you're presenting a bunch of short clips, for those of us who find a browser on a close-up high-res screen much more readable than the TV on the other side of the room, etc etc.) Obviously, this would be optional, so the existing behavior of streaming directly to the browser still works for those who want it. Originally, it looked like the way to do this was to send a different URL to the browser such that the image link ran a cgi script that then talked to the frontend (which might not be the same as the backend machine), and which then ran mplayer right on top of the frontend GUI. This is inelegant in a number of ways, though. But with the recent work that went into SVN (courtesy of the bounty that was paid for the added functionality) for remote-controlling the frontend from elsewhere, this could be a lot easier: Each of the rows in MythWeb's recorded-programs page has a URL that runs a cgi script that gets handed some ID for the program (whatever's easiest to put in the URL and look up in the DB later), and the cgi script then commands the frontend to play that recording directly, just as if the user navigated there via the frontend's UI. Seems very simple. The clean way to implement this would be to augment MythWeb to run an arbitrary script (e.g., the cgi script gets configured to call one of potentially several scripts, and hands it the program ID), and the first (but maybe not only) script to actually get written would be the one that takes the program ID and tells the frontend remote-control to play it. MythWeb would need two additional configuration options somewhere: o Whether to enable this behavior at all o Which frontend to use, if there is more than one How feasible does this sound? ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Should a SBE/FE be running mysqld?
Date: Mon, 30 Jan 2006 13:03:14 +1300 From: Nick Rout [EMAIL PROTECTED] See the other replies, but don't just remove the script, use your distro's tools to make sure it stops and won't start again. Sure; I was speaking informally. By delete I meant use update-rc.d (Ubuntu's name for it) to remove the various symlinks---but your explanation might be useful to somebody else who comes across this... Tnx. (I'm reasonably sure that mysqld was there in the first place because I built the two machines by building one partway and then essentially cloning its disk; obviously I missed a step in getting its services customized.) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Tivo to Myth migration
Date: Tue, 24 Jan 2006 02:15:28 -0800 From: Ian Forde [EMAIL PROTECTED] not sure if anyone's even remotely interested in this, but I've cobbled together a script that will pull a show from a S1 Tivo and put it into the Watch Recordings screen on myth. The script still needs some finishing touches though. (Okay - it's pretty rough to look at. That's very slick. We're actually in the process of migrating from TiVo to Myth right now as we cut over our research platform, so this could come in quite handy. (I've had a network interface in the box for years, but never really used it; this is an original series 1 TiVo running 3.0-01-1-000.) Do you or anyone else happen to know of a way to migrate (or at least pull out, so I can run perl scripts or Emacs macros or whatever) the season pass and wishlist information? We've currently got a combined SP/WL list of at least 400, and it'd be nice to convert those into the appropriate mysql rules for the Myth, so someone doesn't have to type in every single one by hand (at least this time with a real keyboard, unlike the TiVo. :) Something that goes all the way would be most excellent, but even something that just dumps the SP/WL into a file that could be massaged would be better than sitting there with both UI's side-by-side on the screen, transcribing rules... Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Blank channums in mythweb?
In .18.1: I just noticed that about half of the channum fields in my mythweb Recorded Programs page are blank---there's just a lonely little dash instead of a digit, a dash, and a callsign. There doesn't seem to be much of a correlation with callsign, date recorded, whether or not it was a manual recording, etc. Any idea what might cause this? I -did- rearrange my lineups around the 16th, but I see blanks in shows recorded both before and after that date. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Should a SBE/FE be running mysqld?
I recently noticed that my SBE/FE machine has a mysqld running. I'm guessing that there's no reason for this to be the case, since presumably the only place mysqld should be running is on the master backend, but I figured I'd check, just in case. (I also assume I should just remove its startup script from /etc/init.d and call it a day if it's not supposed to be there.) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Peculiar differences in PVR-350 init vs closed-captioning vs LiveTV
This is not the most useful bug report, because it's based on 0.18.1, and I know that LiveTV is completely rewritten in soon-to-be-.19, but just in case it rings any bells or helps anyone: I just noticed that something about MythTV inits a PVR-350's closed-captioning decoder differently depending on whether it's playing recorded stuff, or LiveTV. Since in both cases stuff is really coming from disk, I assume that LiveTV does something extra to init the card that playing a recorded program does not. Specifically, I have recordings done on 250's under ivtv 0.4.1-r1, and my 350 in the frontend (different machine) is using ivtv 0.4.0. If I try to play any of those recordings with a freshly-booted front end (doesn't matter if it was a simple reboot, or a shutdown with several minutes of power-off), the closed captions sent to my TV's CC1 decoder are garbled in a curious way---as if the slicing has misplaced groups of characters. For example, I'll see this CC: day'ToSchus r prles inesotio mn instead of this: Today's Schuler press in motion However, if I watch LiveTV---even if I do so during a commercial break when no CC data is being transmitted---then I can play recordings after that with no garbling of their CC data, until the next time I reboot the frontend. Also, LiveTV's CC data is never garbled. I'll test this again once .19 comes out, but I'm hoping that whatever card initialization -was- done for LiveTV (only) in .18.1 is -still- done (always) in .19, or going to .19 may permanently break CC decoding for me. (Unless this is known to be an ivtv-specific problem fixed in 0.4.2 or one of the later series, but since its behavior changes depending on whether I've viewed LiveTV, well...) If someone else can either reproduce this in .18.1, or try to reproduce it in SVN, that would be interesting data as well. I've tried this on a variety of recorded channels, and some of those channels were recorded at the default 4500kbits/sec, while others were recorded at 3200 or so. Same behavior. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Have any Ubuntu users had good luck with tcrequant?
[Since people here have often mentioned it, I thought I'd ask here as well as pursuing it via the Ubuntu lists and transcoder lists.] I just tried the simplest possible test with transcode's tcrequent. Under Breezy, with either the shipped version (transcode 1.0.1) or the latest (1.0.2), it segfaults, presumably somewhere in an included library, on at least two-thirds of the files I give it, a variable number of megabytes in. (These are files produced by a PVR-250 at the default 4500kbits/sec video rate.) Under Hoary, it finishes, but running it with default options (just -i, -o, default requantization of 1.5) produces an mpeg that's shot through with blockiness and no real audio (just clicks and screeches) when played with mplayer---and which crashes a 350's decoder and also has flickers and stuttering and repeats in the small inset display when browsing recordings. (I tried running mythcommflag --rebuild on it just for yucks; no change, but I wouldn't have expected one.) Clearly, it's broken. Anyone have any Ubuntu success stories w/it? (All .debs, except the 1.0.1 included w/Breezy, are from http://www.hezmatt.org/~mpalmer/ubuntu/; please be considerate of his bandwidth and don't download them unless you're testing this.) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] getting more pissed off about IVTV
Date: Thu, 26 Jan 2006 12:00:03 -0500 From: Richard Bronosky [EMAIL PROTECTED] Well, the moderator finally reviewed my 4 emails to the ivtv-users and ivtv-devel lists. And I got a unanimous up yours from him. This is very sad. You were rejected by a misconfigured computer program, not a human. It's unfortunate that this has cost you a week of angst and hard feelings, but you're not the first to have tripped over this. As your bounces make clear, you were sending to the old, decommissioned lists at sourceforge, and -not- the current lists at ivtvdriver.org, probably because you found the sourceforge lists via a search. I've complained in the past that this is a smoking gun waiting to screw people, and it looked like you just got burned (to mix three metaphors together in a lovely stew). In theory, someone will eventually manage to get sourceforge to take those lists down -and-, one would hope, to put big, prominent warnings all over their archives and any other pages that everything there is obsolete and that people should be looking at ivtvdriver.org instead, but apparently it hasn't happened yet. (Marking interior pages are important because often people find those via search and never see the so-called toplevels.) It's -particularly- unfortunate that the current list configuration actually lets you -attempt- to subscribe and/or post, but then bounces all attempts after a multi-day delay when some internal timer expires (because no human has approved the request yet, because no human is even reading the requests). This makes it -look- like what you tried should succeed, and that somebody's being deliberately unhelpful, and is an even worse fakeout than just obsolete pages that haven't been updated in months. I'm CC'ing ivtv-devel in the hopes that someone might be able to really get this situation fixed. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Bitrate oddity
Date: Thu, 19 Jan 2006 21:40:17 + From: Nick [EMAIL PROTECTED] On 19/01/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Still looking for suggestions on easy ways to either reencode what I've already got at slightly lower rates, or to cut it in ways that will not be too difficult.. For cutting that works, I always recommend ProjectX, a Java app. However there is a lot of work going on to get exporting/transcoding from within MythTV working without the associated audio sync problems that can occur. To simply reduce the size of an MPEG2 file, you can use tcrequant to requantise the video stream without having to reencode the whole thing. It's very useful if your recording is slightly too big to author to DVD, as it takes only a few minutes to work its magic, whereas reencoding could take a long time. tcrequant is part of the transcode project/package. Well, I just had a total bombout on both ideas. I'm running Unbuntu Breezy, in case anyone has any suggestions. What follows are sketchy summaries; if someone wants more details to help debug, I can include precise versions and transcripts from my Emacs shell. ProjectX won't run, regardless of whether I compile it myself or use a premade jarfile I found on doom9; I'm using free-java-sdk. For the one I compiled myself, doing java -jar ProjectX.jar blew out just after saying Loading Basic Classes... saying it couldn't load the AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit. So I installed libcj6-awt and reran it, whereupon it printed Loading Basic Classes... and then simply printed Aborted with no other output and no clues at all as to what went wrong. The premade jarfile I got blew out claiming it couldn't resolve the class net.sourceforge.dvb.projectx.common.Start, even though I grabbed the src directory from the version I compiled and put it in the same place in the tree I got from unzipping the premade jarfile's zipfile. Maybe it's some classpath thing; I dunno. Meanwhile, the Breezy .deb for transcode -appears- to be just fine, but running tcrequant -i inputfile -o outputfile simply segfaults after outputting 17meg of a 290meg testfile (generated straight from one of my PVR-250's at 4500 kbits/sec). And the binary is stripped, so gdb is no help; I'll have to dig up the source and compile myself and then see if it segfaults again and if so, where. (And by the way, is there -any- documentation for tcrequant besides running it with --usage and getting really unhelpful stuff like -d mode `verbosity mode' with no other explanation? It has no manpage, transcode's manpage doesn't even mention it, and I can't seem to find a manpage or documentation on the web. Documented only in its source perhaps?) Does anyone else running Breezy have working versions of either of these two programs? Otherwise, I'll have to go in and debug one or the other of these messes... Tnx. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Changing width resolution for PVR-250/350's
Date: Thu, 19 Jan 2006 16:49:00 -0800 From: Drew Tomlinson [EMAIL PROTECTED] I've found the info at this site helpful http://www.mediachance.com/dvdlab/tutorial/bitrate.html Gosh, that's a pretty diagram. :) I eventually settled on 3200kbits/sec as being just about as good as 4500, and sufficiently small for my needs. Interestingly, at least at that rate, changing the resolution from 720x480 to 640x480 made no apparent difference at all, so I left it at 720. (Maybe I'd see something if I did something extreme like 480x480, but since the apparent quality at 3200 is very close to 4500, it's probably not worth fiddling with it much more.) Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Bitrate oddity
Date: Fri, 20 Jan 2006 13:27:35 -0500 From: Michael T. Dean [EMAIL PROTECTED] On 01/20/06 04:24, [EMAIL PROTECTED] wrote: Well, I just had a total bombout on both ideas. I'm running Unbuntu Breezy, in case anyone has any suggestions. What follows are sketchy summaries; if someone wants more details to help debug, I can include precise versions and transcripts from my Emacs shell. ProjectX won't run, regardless of whether I compile it myself or use a premade jarfile I found on doom9; I'm using free-java-sdk. And that's the problem. Er, care to be a bit more specific? I'm guessing you're saying that there's something wrong with free-java-sdk, but it's pretty unhelpful to have no idea why you say that. Is it only that ProjectX is known not to compile there, or that it's a bad compiler in general, or what? My other choices include, e.g., j2sdk1.4, which is Blackdown, and requires accepting Sun's EULA. Got anything to say about using that one? Or any recommendations about what -else- to try? ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Bitrate oddity
I've just noticed that the claimed bitrates for MPEG-2 encoding seem at least 10% lower than what's actually being written. [And there's question about how to reencode these way at the bottom of this...] I don't see discussion about this in the archives anywhere. I'm using PVR-250's/350's, w/bitrate of 4500 and max bitrate of 6000 (e.g., the defaults). I typically record 64 minutes per 1h show (e.g., I pre- and post-roll by 2m). The resulting files are all within 1% of 2,500,000,000 bytes (written this way so you know I mean decimal bytes, e.g., 2.5 gigabytes and -not- 2.5 gibibytes.) But if you actually do the math... dc 4500 1024 60 64 *** 8 / f 221184 ... it's pretty clear that 4500 kilobits/sec -should- be generating only 2.2 gigabytes in 64 minutes. (And that's assuming that the use of kilobits in the UI really means 1024 bits, and not 1000 bits, or the discrepancy is even larger.) Is there some protocol overhead in the resulting files that's not being accounted-for in the claimed bitrate? And what exactly does max bitrate mean? I presume it means it allows bursts above 4500, but how often? Is there a limit to how often or for what length of time this burst is allowed, or is in entirely dependent upon exactly what's being encoded? (This 2.5-gigabytes-within-1% behavior is consistent across something like 50 hours of video.) This tripped me up because I naively assumed that two 64-minute recordings would easily fit on one 4.7 gigabyte DVD, but when I looked at the file sizes just now, I discovered that they won't--- since each is actually 2.5 gigabytes. (If I cut the pre postrolls off---currently painful in 18.1 because there's no easy way of editing MPEG2-MPEG2, or am I mistaken?---then they'd -just- fit, because 2.5 times 60/64 is 2.34 and twice that is 4.68---a squeaker. Note that I'm planning on recording them as raw data files, not as something playable directly in a DVD player.) Obviously I can adjust my bitrate down slightly for future recordings (is there any particular reason that 4500 was chosen as the default? does it match some other bitrate in something else, for example?), but it's peculiar that this doesn't match. (At least, since I know how much bigger than I than I was expecting, I can calculate the correct so-called bitrate in the UI, which works out to be about 4200 or less---but it's weird that it works this way.) P.S. Suppose I'd like to adjust the bitrate of the existing 50 hours of recording down slightly, so I can easily get them on DVD's without spanning. I've seen lots of various tools fly by on the lists, but it's still not clear to me what the easiest way of doing this is. Does anyone have any suggestions for some easy, preferably scriptable (e.g., command-line only) Linux-based tool that I can use to generate slightly lower-bitrate versions of these files? Thanks! (I'd rather not transcode them to MPEG4 until I figure out why that's giving me audio at very low levels, and I'm -hoping- that whatever tool can readjust the bitrate on these can -preserve- the closed-captioning data currently in these (VBI sliced NTSC from the Hauppauge cards), but don't know if that's too much to ask... Or an easy tool that I can use to cut, say, one commercial segment out of each, hopefully again without destroying the CC info, but I'll take what I can get...) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Bitrate oddity
Date: Thu, 19 Jan 2006 08:50:46 -0500 From: Boleslaw Ciesielski [EMAIL PROTECTED] AFAIK, audio has it's own bitrate and it's not counted as part of the video bitrate. Aha! So bitrate in the UI is video bitrate and not overall bitrate. Still looking for suggestions on easy ways to either reencode what I've already got at slightly lower rates, or to cut it in ways that will not be too difficult.. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Bitrate oddity
Date: Thu, 19 Jan 2006 21:40:17 + From: Nick [EMAIL PROTECTED] On 19/01/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Still looking for suggestions on easy ways to either reencode what I've already got at slightly lower rates, or to cut it in ways that will not be too difficult.. For cutting that works, I always recommend ProjectX, a Java app. However there is a lot of work going on to get exporting/transcoding from within MythTV working without the associated audio sync problems that can occur. Yeah, I've been noticing that, but since I'm still running 18.1, was mostly discounting it until .19 is released... To simply reduce the size of an MPEG2 file, you can use tcrequant to requantise the video stream without having to reencode the whole thing. It's very useful if your recording is slightly too big to author to DVD, as it takes only a few minutes to work its magic, whereas reencoding could take a long time. tcrequant is part of the transcode project/package. Excellent! Thanks; I'll check 'em both out. I'd seen ProjectX's name go by, but it seemed the subject of some controversy (mostly, I guess, when it came to actual integration into Myth), and I couldn't quite recall the tcrequant name. (You have no idea how hard it was not to title this original thread 4500: A Bitrate Odyssey :) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Changing width resolution for PVR-250/350's
Date: Tue, 17 Jan 2006 21:27:59 -0400 From: Greg Estabrooks [EMAIL PROTECTED] But I also saw a neglible change in file sizes, too. Is this the expected behavior? Certainly, bitrate is bitrate regardless of the resolution. 2Megabits at 480x480 is just as much data as 2Megabits at 720x480. Oh duh. Of course; I totally wasn't paying attention to the bitrate page. Well, we already knew I was an idiot... :) The difference is how much data per sampled pixel. Often lowering the resolution and turning up the bitrate can increase picture quality but it also depends on just how clean your source is to start. If you've already got a clean source then you can get away with a lower bitrate. Does anyone have suggestions for -their- ideas of reasonable bitrates before I spend a bunch of time experimenting? I have a clean feed, and I've been reasonably happy with either TiVo High quality, or VHS EP mode quality (yes, I know the latter is substantially fuzzier, and yes, I'm not even talking SVHS :). Approximate figures for either one would make good starting points for my experimentation. (And if anyone thinks that some particular width x height should go along with these bitrates, by all means, share.) Since there's both a bitrate and a max bitrate (4500 and 6000 in my current setup, which are the defaults), there are a lot of variables; are their any I should stay away from? Is it sensible to lower the bitrate to, say, 3000 or even lower, and does it make sense to leave the max bitrate high? Is this used only during a scene change or lots of motion/flow? I'm using a 350 as my TV-out; has anyone noticed any particular bugs/crashes/artifacts from using other bitrates? Plus analog cable broadcasts are normally broadcast in a resolution of close to 544x480 in most markets. People keep focusing on 720x480 as it is the most well known NTSC DVD resolution. Right. I didn't restart mythbackend after each set of changes, and I'm not sure if they take effect instantly or not.) They would take effect immediately so the next time a recording is started they would use the new profile information. Good. mplayer or something, would using 640x480 or some other size make for a more reasonably-transportable setting? Any other comments? What do you mean by transportable in this context? Personally all of my recordings are done at a resolution of 544x480, but of course ymmv. Basically, if I decide to move these recordings elsewhere and watch them on a computer, my guess was that the less rescaling has to happen, the better. Since the input material is all 4:3 SD NTSC, my guess is that I should specify a ratio of width to height that's -also- 4:3, meaning that no pixels need rescaling if I were to just display this stream in mplayer or something. Is this likely to matter? (That would work out to 640 x 480, of course.) Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Changing width resolution for PVR-250/350's
I noticed recently that my 18.1 Myth had a mix of 480x480 and 720x480 resolutions for the Default/LiveTV/High/Low capture resolutions. I'm using 250's 350's (no HD) from an NTSC cable feed, and I tried changing all four of Default/LiveTV/High/Low to 480x480, doing a 1-minute recording, and then changing them to 720x480 repeating it. I didn't see a noticeable quality difference, which might make sense for a typical analog cable feed. But I also saw a neglible change in file sizes, too. Is this the expected behavior? (Naively, I'd sort of suppose so, because they -looked- the same. But I didn't restart mythbackend after each set of changes, and I'm not sure if they take effect instantly or not.) If I think I might be playing these back outside of Myth, maybe with mplayer or something, would using 640x480 or some other size make for a more reasonably-transportable setting? Any other comments? Given that it doesn't seem to make any difference, I'll probably change these back to 720x480 just in case (since it doesn't seem to make the files bigger, and, who knows, might help someday), but if anyone has any words of wisdom, I'm listening. (The HOWTO mentioned this topic a bit, but didn't cover this, and unfortunately width, height, quality and so forth are too vague to be getting good search results back.) Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Slightly OT: receiver input buzzing/humming
Date: Tue, 17 Jan 2006 23:20:40 -0600 From: Meatwad [EMAIL PROTECTED] All excellent points! Only one question: - If same circuit is not possible, try moving all HT equipment to circuits fed from the same side of the panel if you have 120Vac mains. Are you trying to say, put everything on the same phase if you have two-phase service? If not, I'm not sure what you're trying to say. If so, then that isn't necessarily how to do it, since most residential two-phase panels actually have alternating phase going -down- the box, e.g., if you have two rows of breakers, the phases are most likely to be: A A B B A A B B ...etc all the way down; it's done this way so you can put in a two-phase breaker for things like electric stoves dryers. (If you have any of these, they're instantly obvious because they're actually two breakers (typically 30A) tied together mechanically so that if one trips, both trip.) Anyway, let's hope the original poster writes back and says he's found the problem, whatever it was... ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Setting up an FAQ for LiveTV changes
Date: Sun, 15 Jan 2006 14:21:16 -0500 From: Tom E. Craddock Jr. [EMAIL PROTECTED] Jens Baumeister wrote: Hi, since the LiveTV changes seem to lead to questions again and again (and sometimes to flamewars), I volunteer to write an FAQ about it. However, while I do know how things are currently working, I'm not 100% sure about the planned state for the 0.19 release. (Esp. from the user perspective: What setting are planned, etc.) I'd be grateful for any pointers to resources (bug tickets, list threads) I can mine for further information. That way, we'd have a single place to point people to when the question comes up again. Jens You mean besides the archives at gossamer-threads for the -users, -dev, and -commit lists? [Someone's volunteering to make the documentation better, and you're actively trying to discourage him? Why? Not to mention that this sort of documentation has to be written -sometime- as part of a user manual, right? Presumably the end state is for the way LiveTV operates to be documented somewhere, the proposed FAQ would be a good start at getting that written.] In any event---yes, in addition to the archives. Searching archives is a poor substitute for organized information in a central place. The archives are huge (2400 messages/month! 14 meg/month!); poorly organized (threads often wander); and invariably contain large amounts of outdated information---by definition, most of it is old. Further, it's never clear from any given message whether some later message might obsolete it---and it's often hard to tell, since it's very hard to prove a negative, e.g., that there -isn't- some other message/ thread that, if only you'd used a slightly different search term, you'd have found. People who don't also subscribe to all the lists may not know that there's been a discussion about something, hence won't know if they've used the wrong search term and failed to find it. Finally, even if you succeed in all that, searching through archives is very time consuming compared to just reading a web page---and the web page could have author(s) and a modification-date and a here are exactly the versions we're talking about and not these other versions over here and all sorts of other contextual data that would make using the information a whole lot easier. If information changes that obsoletes a wiki page, it's likely someone will update it. If an old thread gets obsoleted, it will -never- get updated, but it won't be obvious where the new information is. And regardless of whether you think that the information is theoretically available in the archives, it clearly isn't available enough in practice, or we wouldn't have exactly the problem that Jens is trying to solve---namely that the list is full of people asking the same questions about LiveTV over and over. That stuff is clearly already in the archives, and clearly not being found. He's proposing to save everybody a lot of time (the questioners, the answerers, those who read the list and have to wade past the same questions a lot), and I'd think that anyone who's offering to do this should be showered with candy and flowers, not made to justify his actions for a situation that's obviously chewing up peoples' time and leading to flamewars and hard feelings. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Setting up an FAQ for LiveTV changes
Date: Sun, 15 Jan 2006 23:29:39 -0500 From: Steve Adeff [EMAIL PROTECTED] http://www.mythtv.org/wiki/index.php/Main_Page ...and your point is...? If you were trying to say, there's already a centralized place where this info can go, I never said there wasn't, and I don't think anyone involved in this discussion thought there wasn't, or didn't know where it already was. If it was and the information Jens wants to write about is already there, then a more-specific URL would have been in order. If it's I have refuted everything you've said with a single pithy one-liner, then you've missed the point entirely---which was my attempt to defend Jens (who'd volunteered to do a nice thing and was asking for suggestions that would let him to a better job more quickly) from pithy one-liner snipes that seemed to be trying to discourage him from doing just that. I'm going to assume that I've just misunderstood you (and, for that matter, that everyone, including me, simply misunderstood the intent of Craddock's original message), and let's move on. Let's please not let one ambiguous brief response get in the way of someone trying to make things nicer for everyone. (And -way big kudos- to Michael Dean for that impressive list of URLs! That's a really great set of topics, all in one message, and I hope it all winds up in Jens' FAQ---should stamp out of a lot of random questions all in one shot, especially when 19 is released and everyone who hasn't been reading -dev and maybe not even -users tries it and would otherwise get really confused... :) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] install ivtv-0.5.1 fails with ivtv: disagrees about version of symbol tveeprom_hauppauge_analog (make distclean doesn't help)
Date: Sat, 14 Jan 2006 19:57:50 -0500 From: R. G. Newbury [EMAIL PROTECTED] This piece of advice in the wiki is (now) backwards: There is work at the moment to merge these conflicting versions, but in the meantime the kernel version has to go: Can you double-check (from archives, Hans, or some other source) that this is true, and then update the wiki so people don't get confused? (Or, if you'd rather not update the wiki, I will, but I'd rather get a second opinion on this, since I don't have direct experience with either 500's or pc3000's. And is this something that's changed between 0.4.0 and later versions? If so, updating the wiki will have to account for that and speak the truth in all cases. I've been tweaking the ivtvdriver wiki a little bit, but the last thing I'd want to do is update it incorrectly.) (I'm a big believer in shoving as much information and operational experience into the ivtvdriver and mythtv wikis as possible, since it should decrease traffic and frustration a lot if all this stuff can stay centralized instead of requiring lots of list searching---with its uncertain keywords, outdated and incomplete information, and all the rest... :) Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Why is my 350's audio so much l-l-louder! than the 250's?
I just noticed a peculiar situation: Running 18.1. MBE has several 250's with ivtv 0.4.1-r1. SBE/FE has 1 350 with ivtv 0.4.0. LiveTV uses the 350 because I have avoid conflicts checked and the 350 is in the FE. Cable feed is split across all of them into their RF inputs. Everything is getting played back through the 350's AV output, and the 350's audio out is looped through my sound card and then to the TV. If I leave all the sliders in the recording profiles for Default/ LiveTV/High/Low quality at 90% (the default), and then start recording on all tuners on various channels, whatever the 350 is recording has MUCH louder audio (6-9db, as measured by my trusty dB meter) than the 250's. If I have the Master and PCM sliders in general setup set to 90%, then on my equipment, this happens to mean that anything on the 250's plays back somewhat quieter than direct to the TV (I can dual-screen the TV and flip back and forth between direct from the cable feed or through the Myth box), while the 350 plays back somewhat louder. If I raise the Master PCM sliders to 100%, then the 250's essentially play back at the level of the direct-to-TV path, but then the 350 is playing back MUCH louder. (When I say playing back, of course, I mean when I play back a stream that was captured by that card.) This is true for the 350 regardless of whether I'm using it in LiveTV mode, or it's capturing just like the rest of the tuners for a scheduled recording. I can't just lower the slider for LiveTV and leave it at that, because I'd like shows recorded by the 350 to have the same approximate volume as those recorded by the 250's. Yet I can't seem to find any independent volume control per-tuner, and I don't understand why this one card would be capturing as such a high level anyway. (And if I raise all the sliders in the recording profiles to 100%, the 250's still give me reasonable audio---just somewhat louder, of course---while the 350's audio is so hot that it's clipped and objectionable.) Is this a well-known effect? Is it peculiar to 350's vs 250's, or between ivtv 0.4.0 and 0.4.1-r1? Is there some register I should be setting on the 350 or something? I -could- try installing 0.4.1-x or even 0.5.x on the 350, but I'd rather leave well enough alone unless it's likely that this will fix it, since I had problems a while back with sporadically vanishing audio on ch2 and would rather not disturb the situation and possibly wind up back there. [Btw, ivtvctl -Y reports volume = 58950 for both the 350 and the 250's. By trial and error (switching between LiveTV's output and the TV's direct input from cable), I find that ivtvctl -y volume=54000 on the 350 normalizes its audio level to that of the TV; I'll have to play around a little more to make sure that also means it's normalized to the 250's. But why should I have to adjust this down so much? (And it won't stick! Changing channels or leaving LiveTV is fine, but reentering LiveTV bashes the register back to 58950! Is there any way to make this stick, as a workaround?)] Thanks for any insights. (Unfortunately, swapping the 350 into the other machine just to test ivtv versions w/o reinstalling anything would probably be a fairly large pain, given that I'd have to schedule up some recordings in advance, let it go, and then swap back to see how they went---and because the machines are both headless unless you count the 350. So I'd rather not swap hardware if there's another way to debug.) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Why is my 350's audio so much l-l-louder! than the 250's?
Date: Thu, 12 Jan 2006 05:02:33 -0500 (EST) From: [EMAIL PROTECTED] (And it won't stick! Changing channels or leaving LiveTV is fine, but reentering LiveTV bashes the register back to 58950! Is there any way to make this stick, as a workaround?)] ...and before anyone else suggests it, yes, I suppose I -could- employ the stomach-turning kluge of playing whack-a-mole with the register value, such as having a background process blindly set it to the right value once a second, or perhaps check it once a second and reset it if it's strayed. If it only gets reset just as the card goes into capture mode, this means that on average only the first half-second would be too loud, and the card might still be acquiring and/or unmuting then anyway. But it'd be better to figure out why I need to do this in the first place---and, failing that, if there was some general hook that gets run before the card goes into capture mode (whether for LiveTV or scheduled recording) on which I could hang the appropriate command, without having to recompile 18.1 just to add such a hook...). ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Why is my 350's audio so much l-l-louder! than the 250's?
Date: Thu, 12 Jan 2006 12:19:45 + From: Ant Daniel [EMAIL PROTECTED] From my reading of the ivtv list I know that there are differences between sound levels of 150/500 250/350 but I thought that the 250/350 was consistent. Apparently not. See below. It might be worth checking on with ivtv list if there should be a difference in sound between these. I CC'ed my original message to ivtv-users, and Hans replied, but only to that list: Date: Thu, 12 Jan 2006 19:11:33 +0100 From: Hans Verkuil [EMAIL PROTECTED] In general it is next to impossible to make any assumptions on the volume level captured by a card: it depends on the make, model, chips used, tuner used, signal quality, etc. I have two pvr350 cards, one an old model, the other new and they have totally different recording levels. Does anyone know if a per-card audio level is already present in SVN? I couldn't find any mention of it in the archives for the -dev and -commit lists, but I don't run SVN. I'd be perfectly happy to open a ticket for this issue, assuming that it's actually going to be viewed as a bug and not a feature request without code; would any developers care to weigh in? (Note that people who have entirely different brands of cards mixed together and/or both analog and digital sources -really- shouldn't be expected to have them all have similar levels without the ability to individually adjust 'em...) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Hauppauge PVR Questions
I got mail back from Bryan about his results in comparing the 150 to the 250; see the two messages below. - - - Begin forwarded message - - - Date: Thu, 12 Jan 2006 10:54:16 -0500 From: Bryan Mayland [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Date: Wed, 11 Jan 2006 14:31:36 -0500 From: Michael T. Dean [EMAIL PROTECTED] The 150 is a better card (it even has a potential to give a better picture quality than the 250) and saves you money. bmayland (CC'ed) started a thread on 15 June 2005 showing dramatic differences in sharpness between the two cards, with the 250 winning. He also said he'd do some more experimentation; Bryan, did you come up any any further results? (I'm particularly interested in RF-in, but I also use composite-in.) Yes. Yes I did. For reference, here was the image where I compared the two: http://capnbry.net/~bmayland/fi/pvr150/pvr150-250.jpg The problem in the second image is that the luma and or chroma comb error limit was exceeded, which then forces the card to go back to regular ole notch mode Y/C separation. To fix this up, I use cx25840ctl to up the CCOMB_ERR_LIMIT from 80 (default) to 120. Note that my PVR-150 is i2c device 1: echo CCOMB_ERR_LIMIT=120 | cx25840ctl -s 1 The PVR250/350 also defaults to using a +5.5dB luma sharpening filter, this can be approximated on the PVR150 with: echo PEAK_SEL=2 | cx25840ctl -s 1 echo PEAK_EN=1 | cx25840ctl -s 1 I find this to be too much on the 150, so that PEAK_SEL can be adjusted from 0 (+2.0dB) to 3 (+6.0dB). I encourage anyone who wants to look into it to run their own tests to see what's best for them. Settings: PEAK_SEL=0-3 PEAK_EN=0-1 (default 0) Turn on luma boost (sharpening) LCOMB_ERR_LIMIT=0-255 (default 20) Luma comb err limit before falling back to complemenatry mode CCOMB_ERR_LIMIT=0-255 (default 80) Chroma comb err limit before falling back to notch mode LLCOMB_2LN_EN=0-1 (default 1) 2 line luma comb filter enable LLCOMB_3LN_EN=0-1 (default 1) CLCOMB_2LN_EN=0-1 (default 1) CLCOMB_3LN_EN=0-1 (default 1) COMB_NOTCH_MODE=0-2 (default 1) What to do with notch data (0 = disable, 1 = notch is chroma, 2 = notch is 50/50 luma/chroma, 3 = notch is luma - - - Separator between forwarded messages - - - Date: Thu, 12 Jan 2006 15:01:24 -0500 From: Bryan Mayland [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Do you find that this tweaking, at least for your sources, gives you the same quality on the 150 as you were getting on the 250? I kinda go back and forth on this and I'm not sure which I like best. Here's a cap from my 150 which I think looks great except for the interlacing and the tint is slightly too red: http://capnbry.net/~bmayland/fi/pvr150/sample-news.png Deinterlaced: http://capnbry.net/~bmayland/fi/pvr150/sample-newsdeint.png (Though given the audio-level differences people are mentioning, I wrote the volume control for the cx25840 in ivtv so I don't have this problem. Apparently some cards are to spec and mine is not, so therefore what is right on my card (which I know is not right according the the datasheet) is not right on other cards. and the current lack of closed-captioning reverse-engineering, I may stock up on 250's before they vanish, even if 150's or 500's might be a theoretically better idea...) On the plus side, the 150 does run slightly cooler and draw an insignificantly lower amount of power. :) Can I forward your response back to the list? (I'm assuming the answer is yes, since that's what you were trying to do in the first place, but I figured I'd ask just in case...) Please do. I was trying to get it there in the first place, I didn't know I had to be a member to post and I haven't had time to go sign up just to send one message. - - - End forwarded message - - - ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Hauppauge PVR Questions
Date: Wed, 11 Jan 2006 14:31:36 -0500 From: Michael T. Dean [EMAIL PROTECTED] The 150 is a better card (it even has a potential to give a better picture quality than the 250) and saves you money. bmayland (CC'ed) started a thread on 15 June 2005 showing dramatic differences in sharpness between the two cards, with the 250 winning. He also said he'd do some more experimentation; Bryan, did you come up any any further results? (I'm particularly interested in RF-in, but I also use composite-in.) Also, ivtv can't do NTSC sliced VBI closed-captioning on the 150/500 yet, because Hans and the rest of the ivtv crew haven't been able to reverse-engineer that part so far. The 250/350 do it just fine. (If the sharpness and CC differences between the 250/350 series and the 150/500 series get resolved, then my next purchase will be a 500, but until then, I'm going to waste PCI slots and get 250's since they'll work better for me. Assuming, of course, they're still being made at that point---I sure hope so.) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Slightly OT: receiver input buzzing/humming
Date: Wed, 11 Jan 2006 12:38:56 -0500 From: Steve Adeff [EMAIL PROTECTED] On Wednesday 11 January 2006 10:12, [EMAIL PROTECTED] wrote: After I posted the message, however, I started reading about SPDIF and digital audio IO. Looks like my 7NIF2 lacks the SPDIF header on the motherboard. But I *do* have a Creative SoundBlaster Live in my pile of old components. It's pretty old, but it does have digital out. I'm guessing that a digital cable would not be affected by grounding problems, right? Or at least any grounding effects would not be audible? optical connection yes, coaxial no, since coax still uses a ground which would link the two grounds together. I'd also suggest using a smaller ground wire, 14 or 16, so that if there is a ground fault it will want to travel down the components natural ground instead of flowing through the other component. As well, if you receiver does not have a ground prong then definitely ground it manually with a 12g to the wall socket ground! Eh? If he's sending digital information down the coax, then no amount of ground hum will be audible at the receiver, until the hum is so bad it starts flipping bits in the data stream (at which point, he'll hear either silence or godawful artifacts, depending on the protocol---but it sure won't be 60 Hz hum). Sure, if the problem is ground loops, then anything which can spuriously tie grounds together is a problem. But given the randomly-interconnected nature of computer hardware (much less stereo hardware), trying for a true single-point ground as it done in, e.g., lab instrumentation amps is infeasible. If the coax is supposedly the -only- source of ground interconnection, then going to an optical interconnect might help, but that's a fragile solution. It's ambiguous from the original poster's comment whether the problem is new, or he's just started noticing it. My guess, if the latter, is that the shield on some cable got damaged, or something was recently changed in the hardware configuration elsewhere (new component? new cable?), and certainly replacing cables is the easier quickest way to debug that. If he has another way of producing audio, I'd also try substituting that at the end of the cable, once the cable is known good. (After all, it -could- be that some filter cap in the sound board on the computer blew or is getting leaky; such things do happen.) While experimenting with tying chassis grounds together might be interesting, not all components use that as their signal-ground reference (though most do). It might make more sense to try, just as an experiment, putting all components on a single outlet strip, so you know they're on the same phase and circuit. (I've seen strange currents induced on so-called power grounds when different phases meet through equipment, especially in older structures with poor wiring [which is one reason why certain lab and audio gear keep chassis (power) and signal grounds rigorously separate], and it's always possible that a ground or connection somewhere has gotten ohmic and therefore there's a voltage difference around that, in theory, can't exist.) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Slightly OT: receiver input buzzing/humming
Date: Wed, 11 Jan 2006 17:11:10 -0600 From: [EMAIL PROTECTED] On Wed, Jan 11, 2006 at 04:58:36PM -0500, [EMAIL PROTECTED] wrote: Eh? If he's sending digital information down the coax, then no amount of ground hum will be audible at the receiver, until the hum is so bad it starts flipping bits in the data stream (at which point, he'll hear either silence or godawful artifacts, depending on the protocol---but it sure won't be 60 Hz hum). How bad is bad? :) I mean, there's definately noise between the computer and the receiver. Will I hear random bits being flipped (I assume that noise will cause SOME flippage)? Although I suppose there's some kind of parity or error correction built in to the protocol... If the hum is enough to flip bits (and I doubt it would be), you'd either hear nothing at all (if the protocol suppresses packets with errors) or perhaps fuzz (like clipped square waves or a fuzzbox on a guitar) or perhaps white noise (hiss). Or all kinds of other things. But it's very unlikely to sound like hum. If you take a random MP3 (say) or WAV file and start flipping 1% of the bits, what do you hear? supposedly the -only- source of ground interconnection, then going to an optical interconnect might help, but that's a fragile solution. What makes it fragile? Is it because of the point above, that I might be close to enough bit flipping that I hear garbage? It's fragile because if the only thing keeping the system working is keeping two dissimilar grounds separate, then all it takes is one wire between two components that didn't used to be connected to possibly connect those grounds and give you your hum back. That might amount to adding hardware, or changing what outlet something's plugged into, or even someone touching the cases of both components simultaneously. There are loads of sneak paths, and it only takes one. Better to eliminate the problem at the source than depend on isolating grounds. It's ambiguous from the original poster's comment whether the problem is new, or he's just started noticing it. My guess, if the latter, is that the shield on some cable got damaged, or something was recently changed in the hardware configuration elsewhere (new component? new cable?), and certainly replacing I *think* it's new. If it's not, then it's definately worse than it used to be. And yes, there were *major* changes---I got a new TV, and got rid of the VCR and DVD (mythtv makes them obsolete). Then lots of things might have changed in your cabling, and maybe a bad shield that was papered-over by some -other-, good shield (hence good ground) being connected between two things isn't connected any more---so maybe the problem is that you used to have a better ground connection between one place and another, and now you don't. Or maybe the physical strain of unplugging a cable or plugging it back in broke a marginal solder joint in a shield somewhere. You see the point---you're going to have to start swapping cables so forth around and see if you can get the hum to move around or vanish. (You might also try turning off the TV and seeing if you still hear hum from the stereo. Instead of being induced ambient powerline hum, you -could- be getting hum from the flyback transformer or something else coupling into a signal line somewhere that runs too close to the TV (and has a bad shield). This used to be an issue with power supply transformers, but modern electronics doesn't use transformers in its power supplies any more. And if this TV is in fact not a CRT, there's no flyback, so that's not it either...) cables is the easier quickest way to debug that. If he has another way of producing audio, I'd also try substituting that at the end of the cable, once the cable is known good. (After all, it -could- be that some filter cap in the sound board on the computer blew or is getting leaky; such things do happen.) Hmmm... it seems like my sound card is unusually quiet. Part of the reason I even noticed this problem is that I have to turn up the receiver louder than I do for anything else when using my HTPC (mythtv, xmms, whatever). Even with PCM cranked, I still have to turn the volume more than I usually do. It's possible you're just hearing hum from the soundcard that no amount of cabling can get rid of---the card itself just might be hummy, and you never noticed it at lower volumes. I'd try swapping cables first, then any other sound output your machine can generate, including perhaps a different soundcard if you don't have any other audio outputs available. (You might also make sure that aslamixer claims that all your masters are up, and so forth.) (I've seen strange currents induced on so-called power grounds when different phases meet through equipment, especially in older structures with poor
[mythtv-users] Slightly OT: receiver input buzzing/humming
Date: Wed, 11 Jan 2006 21:11:05 -0500 From: Steve Adeff [EMAIL PROTECTED] you've obvously not deallt much with audio equipment ground problems. ...except, perhaps, in my days doing live audio work for theaters. :) [Aha! I think you said this because I was careless in my phrasing; see a few paragraphs below. No hard feelings. :) ] [I note that going into excruciatingly correct theory on audio signal handling is -way- beyond the scope of this list. So I'm simplifying. (Ditto for how to design the grounds on sub-microvolt lab instruments.) There are actually some interestingly controversial theories about it in the audio field, too, some of which seem like total voodoo, and a lot of religious arguments over it; I prefer the lab-instrument people, who tend to be less argumentative as a rule. And I'm especially glad that I no longer have to nail other peoples' hum problems, particularly during live events.] A ground loop hum/buzz will work its way from the input ground to the output ground to the amp ground, etc, etc. causing hum in the output. Usually the hum will increase in volume as the preamp volume is turned up, depending on the topology, and can be a good way to tell if its a ground hum or powerline hum. I never said it wouldn't. ---oh wait, I see (now) how you read my reply. I was answering the coax-bit-flipping case for the shield missing hypothesis, and you were thinking along the lines of intact coax shield enables ground loops hypothesis, which I didn't get into until the -next- paragraph about tying grounds together. But I got careless and typed ground hum there instead of signal hum. Oops. Total change in meaning due to a braino on my part. Sorry for the confusion. But my suspicion (as I said before) is that all this talk of ground loops is probably bogus. I think he's got a bad signal shield somewhere, or a bad cap, or a bad design. All good home theatre equipment will have at least 1 screw that is an external ground point for helping to solve ground loop problems, though really they are (or were) there to ground record player arms back when people knew what vinyl was. Yeah, but I'll bet his TV and his computer don't, unfortunately. And frankly, they shouldn't need it---the vast majority of stereos get along just fine with no more attention to grounding than make sure you plug all the cables in all the way. Yes, connecting both peices of equipment to a good filtered power strip (Panamax, Belkin PureAV, NOT Monster) will be the best way to solve the Maybe if it's powerline-induced ground hum, which I doubt. I've typically found that concentrating on (and chasing) loops in powerline grounds is counterproductive; it's usually some screwup in the signal paths. Everybody instantly leaps to oh, it's a ground loop! but it turns out to be pretty difficult to really get nailed by that sort of thing in audio work. (I could tell you stories of truly bizarre all-analog line-level (thank god, not mic-level) whole-building distribution systems that, amazingly enough, functioned despite looking like the entire thing would be one giant hairball of loops, but nonetheless were fine if signal grounds were done right. But I digress... :) problem, but may not always work, if the hum is coming from, say, a cable line, or failing capacitor... My current theories. (Or just a crappy soundcard that -always- hums, but was only noticed because he's suddenly turning things up really load to hear unexpectedly faint output---it'd be good to know if he's really maxed out his soundcard outputs and mixers all along the way. Sure, they may distort, but he can back off from that and then see if he still has to turn up the amp so far that he hears hum.) I really think that the most productive next step in this discussion is not to have either one of us keep talking, but to have him start swapping cables (first), then soundcards (second), then maybe what outlets things are plugged into (distant third), but I think that without some experimental evidence, we've reached the end of what anyone can sensibly say might be wrong. So I'll bow out now. :) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Ordering of mysql and mythbackend shutdowns
I've just noticed that, when rebooting the master backend machine, mysql gets shut down before the backend (because, of course, mysql sorts before mythbackend and typically they're both started/stopped w/the same two-digit priority in the rc scripts). This causes the backend (if it's logging verbosely, which mine is) to emit a bunch of lines about being unable to talk to the database just before it dies. (Actually, the complaints seem to be coming from a different pid than the backend while it's running; I'm not sure if it's getting respawned for an instant or what.) I don't care about the warning per se, but I don't know if, when it gets the termination signal, the backend tries to do any sort of cleanup or housekeeping which requires the database. If it does, I suppose I should arrange for the database to come down afterwards. Does this ever matter? I can't seem to find anything useful about this in searching various archives; I'm guessing that the backend never has anything important pending that it wouldn't just write to the database immediately without caching, but I don't know. (I also don't know what would happen to any in-progress jobs such as commflagging; I'm assuming they'd just be restarted upon boot 'cause they wouldn't have been deleted from the job queue.) This is in 18.1, but I suppose it'd be good to know for svn, too. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Ordering of mysql and mythbackend shutdowns
Date: Tue, 10 Jan 2006 05:46:17 -0500 (EST) From: Chris Pinkham [EMAIL PROTECTED] I've just noticed that, when rebooting the master backend machine, mysql gets shut down before the backend (because, of course, mysql sorts before mythbackend and typically they're both started/stopped w/the same two-digit priority in the rc scripts). This causes the backend (if it's logging verbosely, which mine is) to emit a bunch of This is a distribution issue, the distributor is the one who specified the startup/shutdown sequence, it's not in the Myth source code. Oh, sorry, I didn't mean to imply that this was in Myth's code. I just wanted to figure out whether Myth did any sort of DB-related cleanup on termination, and thus whether to ensure that the DB was, in fact, available to it before the backend got signalled. If it doesn't catch the signal (or doesn't do any DB-related cleanup if it -does- catch the signal), than it doesn't matter. Otherwise, I'll rearrange my script ordering slightly (and such a dependency should get documented somewhere). ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Ordering of mysql and mythbackend shutdowns
Date: Tue, 10 Jan 2006 16:18:51 -0600 From: Kevin Kuphal [EMAIL PROTECTED] Common sense says that all applications accessing the DB should be shut down cleanly before shutting down the database. Yes, that's exactly my take on it. But before going to the effort of making my ordering correct (trivial) or of trying to ensure that Debian and/or Ubuntu packagers [once that situation is sorted out] do it right (more work) or of trying to make sure that all the other distros out there do it right (even more work), it'd be nice to know if it's pointless :) If the backend doesn't need to do any cleanup before unexpectedly dying, it may be the case that it just doesn't matter if the DB goes down first. (Or maybe I'll just make it correct for me, and if turns out to be a source of obscure bugs for others, that'll motivate somebody else to fix it in distros.) [It strikes me that, in distros that use S|Knnname-style inits, it would actually make the most sense to run K scripts in -reverse- alphabetical order, making it really easy to establish a stack order (instead of FIFO order) for startups/shutdowns and thus get them nested right without altering the two-digit priorities. But even if that turns out to be technically what everyone would want, there's probably too big an installed base to ever consider changing it now.] ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] How to KEEP mythtv running when user exits
Date: Tue, 10 Jan 2006 16:50:07 -0800 From: John Biundo [EMAIL PROTECTED] Hi all. I've got mythtv starting up automatically upon boot (by running mythfrontend in user mythtv's .xsession). No problem there. But when my wife/kids exit from the top menu by mistake (one too many exit button presses) they're left at the befuddling command prompt. After futzing with inittab to try to get this working, and googling around along a bunch of wild goose chases, I'm throwing my hands up and beseeching the gurus how to do this. If I understand you correctly, you might try putting something like this in mythtv's .xsession: while [ 1 ] do mythfrontend done That way, if the frontend exits for any reason, it'll instantly restart itself. (It -also- means you can't log out of mythtv on the X display directly; you'd have to kill the process running the while loop, or one of its parents, to actually kill the frontend; presumably you'd do this by ssh'ing in from somewhere else---note that a cleaner way would be to make the loop check for the existence of some file, and then just delete the file (again, from somewhere else) and -then- exiting the frontend won't cause it to respawn.) I did this when I was repeatedly restarting the frontend to get various overscan/positioning parameters set correctly (via trial and error), and it was so useful I just left it in place. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] NFS suggestions under heavy load?
I suspect that the answer to this question is, Don't do that, then, but in case anyone has any suggestions: I was doing a load test. Configuration is 18.1, with an MBE w/5 250's and an SBE that NFS-mounts the MBE's recording directory, with 1 350. CPU's are AMD 2800+'s, 512MB RAM, 100baseT ethernet through a hub; disks are Seagate 7200.7 200GB PATA (one per CPU); filesystem for the non-recordings is ext3fs. (Recordings use JFS.) I set up test recordings on all 6 tuners simultaneously, then started a dirvish backup of the entire MBE's filesystem, -excluding- the actual video directory and things like /dev and /proc and so forth; I was doing this in part to set up the initial dirvish vault for keeping the machine backed up. (For those who've never heard of dirvish, this amounts to running rsync on the entire filesystem and schlepping the results to a third machine.) About 1 minute into the transfer (and about 6 minutes into the recording), the recording on the 350 (e.g., the SBE machine) got corrupted for a few seconds that threw off its audio sync throughout the rest of the recording and then crashed the 350 itself when I played back that particular stream a few hours later (more about that in a message to ivtv-users). The slave logged three complaints across 300ms in its kernel log that the master's NFS server timed out while it was making that recording, so I'm hardly surprised that the recording had problems. Interestingly, it only glitched that one time; I'm not sure why. I have real-time commflagging turned on, and the test recordings started about 5 minutes before the rsync, and most of the commflaggers run on the slave, so that added to both disk and network contention. I suppose in retrospect it's not surprising that something hiccuped, and that -was- the point of the test... (Though OTOH the commflagger waits several minutes [exactly 5? more?] before starting, so maybe it wasn't that. OTGH, I have a 10s job-queue check interval, so 5 of them could have started within a 50-second window once enough recording had accumulated.) The question is, can I do better? I don't imagine I'll often be rsyncing the entire disk, but I will certainly be rsyncing the delta since the last rsync, and I'd rather not have to worry about that disrupting recordings. (That's a bit harder to test under load, since the deltas will vary, but I'll attempt it to ensure that rsync's scanning phase isn't enough to cause disruption.) Current NFS mount options are rsize and wsize of 8192; would increasing these help on a 100baseT hub, or just lead to more fragment reassembly? (Actually, the hub itself is an SMC 8508T gigabit hub with jumbo packet support, but the NICs on the CPUs are only 100 megabit.) Other NFS options are soft nfsvers=3, which are pretty standard. Would increasing ivtv's buffer sizes on the slave help? Or would I be screwed anyway 'cause the buffers are already flushed by the time the NFS timeout manifests? P.S. Is it feasible to let the slave record on its own filesystem instead of on the NFS-mounted master's? I suspect that there's no way to seamlessly be able to play, commflag, or transcode if recordings might be split across multiple filesystems, but if somebody has a good idea, I'm willing to listen... Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Scheduling with 2 tuner cards.
Date: Thu, 29 Dec 2005 11:13:42 -0500 From: Michael T. Dean [EMAIL PROTECTED] I have a 10 minute extra recording delay set as the default. This is a global pre-/post-roll. It is not meant to be used as an always record this much before/after--it's supposed to be set to the amount of time it takes your card/disk/etc. to spin up for a recording and or to give an STB's OSD time to disappear. We're talking about the two top items in the first screen of Main - Utilities/Setup - Setup - TV Settings - General in 0.18.1, are we not? I see that its self-documentation says that it doesn't affect the scheduler, but perhaps it would be clearer if your sentence about spinning up and/or OSD disappearance was added. It sure seemed to me, too, that this would be a reasonable way to add a global pre/post roll to things (though I haven't tried it yet), and it wasn't until your message that I took a closer look at exactly what it was saying about the scheduler and realized that it probably wasn't want I wanted in the case of two sequentially-aired shows on the same channel: I'd want each to get its -own- padding (which currently would consume two tuner, and maybe someday in the future will consume only one), and apparently this control won't do it. I found a kludgey way around it by forcing my recording to run 15 minutes over which rescheduled the second show onto the other card. This kludgey way is the way you're supposed to do this. If you need to over-record for a rule, set the over-record on /that/ rule and the scheduler will honor it. If you need it on all rules, set it on all rules. Is there a fast way to do this? Maybe this and part 1 above could be added to the scheduling algorithm in the next version. Search the archives. This has been discussed to death. Some devs (Chris Pinkham/Bruce Markey?) even went to the trouble of writing code to allow hard pre-/post-roll values, but the limited feedback they received combined with the extra problems it created seemed to be enough to cause them to table the issue. Can you provide a more-specific pointer? I'm having a hard time finding this particular discussion in the archives; presumably I'm not using whatever terminology was being used. It seems we're more likely to get a default recording settings that would provide a template to use when creating a new rule (i.e. allows you to set the default to include start early/end late values other than 0). That would certainly be nice. In particular, I'd like to say, by default, pad -every- recording by 2 minutes with a pre- and post-roll. I don't see any way of doing this; it seems that I have to specify it for every program I pluck out of the program guide, or for every recording rule I make. It'd be nice if it could inherit some default values. (If there's some easy way to do this, then I've missed it; can anyone enlighten me?) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Mythweb and episode numbers
Date: Fri, 06 Jan 2006 00:26:57 -0800 From: Chris Petersen [EMAIL PROTECTED] Thanks! I assume it'd be fairly easy for me to look at the SVN patch and backport to 18.1? (SVN is too unstable for me, and I haven't yet looked carefully at how mythweb has changed between the two.) HUGE code structure changes... you could pick at it, but the patch itself definitely wouldn't apply. Okay; I may eyeball this in case I can't wait for 0.19. [*] ??? I'm confused. I was under the impression that feature requests were very much discouraged in trac [ . . . ] I use it for feature requests.. maybe the other devs don't, but that's where people tend to put them, and it's one of the only places to put info that is guaranteed to be looked at. Okay, then that's where I'll send feature requests for mythweb, anyway. But there probably won't be any until 0.19 is released, since I probably can't justify the instability of SVN. [Note that, e.g., trac #952 is an example of something that was apparently closed 'cause feature request without patch attached; I tripped over this at random just now. It also says Read the Ticket HowTo but that page (http://svn.mythtv.org/trac/wiki/HowTo) has never been written, although the actual URL written there after HowTo, namely http://svn.mythtv.org/trac/wiki/TicketHowTo, has.] Anyway, thanks again! [*] A whine: It's really unfortunate that so many milestones are part of the next release; it's somewhat painful to be in the situation of wanting a modicum of stability, but therefore to be running a release that's will probably be a year old before it's superceded and hence is so old that many SVN users can't even remember what was in it, and for which filing bug reports is essentially uselessor, on the other horn of this dilemma, to use an SVN that's so unstable that deliberate weeks-long breakages of features are done on the mainline instead of a branch. I wish we could have stable or even semi-stable releases on better than a yearly schedule, or that SVN used branches more. Oh well. [And, while I'm wishing for a pony, I wish that it was possible to at least use a mix of SVN and stable, but the protocol/schema changes make this impossible, too, so it's quite difficult to have a stable production machine -and- a testbed machine without a lot of duplication of resources and time. Alas, alack.] ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Transcoding on a non myth machine
Date: Thu, 5 Jan 2006 17:29:30 -0500 From: Steve Adeff [EMAIL PROTECTED] On Thursday 05 January 2006 17:11, Jay Ung wrote: I was wondering if it iis possible to transcode .nuv to avi on a machine that is not a mythtv machine using nuvexport.I am a total noob when it comes to transcoding. I would love to use my home server as the transcode machine. The mythtv box doesn't really have the horsepower. But the server is not a backend or have any mythtv stuff installed. If it is possible to transcode this way, is it possible to cut commercials? Basically what I would love to do is record a program, copy it to the server via cron job, cut commercials, and transcode to xvid, then move it back. I would love to do this completely automatically. So am I smoking crack, or is this possible. Thanks, joe I believe if you install a slave backend on the machine you can set it up to do all the transcoding. I do my commercial flagging this way right now, but haven't entered the world of transcoding. You'd sure think this should be possible, but when -I- tried it, by turning on the transcode-every-recording button in the UI and doing nothing else fancy (in 18.1, on a combined FE/SBE which NFS-mounted the recordings from the MBE), I had a number of problems (see traffic from me from a month or so ago). In particular: (a) The SBE's mythtranscode was getting handed myth:// URLs instead of just a pointer into the filesystem, then complained that it didn't support that mode. Jobs on the MBE ran fine, but that meant that some random proportion of them would just error out and die. (b) It then left all the errors in my job queue for some long period of time and nobody could figure out how to actually make them go away. (They appear to have all vanished 8 days (yes, not 7) after erroring, spontaneously; is there some week-and-a-day timeout somewhere?) This was apparent from reading the backend logs, since I've got both backends and the frontend logging to files to -v and have since about 6 weeks ago. (c) The resulting transcoded files had -VERY- low audio levels, and I couldn't find any way of making them at least match the originals. (My recordings in general -also- have low audio levels, despite setting ALSA mixer levels high; is there some way of convincing 250's and 350's to record louder? I'm comparing to the TV itself and all the other devices which share the cable feed, none of which have this problem.) Since I'd rather not have to do all my transcoding on the MBE (which has the majority of the tuners), and since transcoding from MPEG2 to MPEG4 doesn't preserve the closed-captioning information anyway, I just gave up on the whole idea of transcoding. If anyone has any ideas on how to solve (a) and (c), in particular, I'd appreciate it; the relevant traffic is on the -users list about a month ago, but it but there was very little discussion and no resolution. (I now have tools that allow me to dump the CC info from the MPEG2 file into an ASCII file, so I might reconsider transcoding and then having mplayer render the CC info from the ASCII while playing the MPEG4---or figure out a way of regenerating MPEG2 from MPEG4 (preferably, also sucking in the CC data) so I can actually use my -350's native MPEG2 output, but I'd need a solution to the transcoding issues above. It'd sure be nice to take advantage of the space-saving it would make possible.) [-Is- there some easy way of reverse-transcoding, e.g., MP4-MP2? Given that, I could compare the quality of MP2-350, MP2-MP4-350 (using its framebuffer support, which works for me), or MP2-MP4-MP2 and then the 350's native output again; presumably I'd only be doing this if the quality time were acceptable and I really wanted native closed-captioning support, which would require some way to re-embed it into the new MP2 stream.] ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Mythweb and episode numbers
In 0.18.1: In the program_detail page, is there an easy way of also displaying the episode number, for cases in which that data is available? Some channels often don't have real titles for their shows, or don't make it clear that there are two parts with identical titles but different episode numbers; having this info in mythweb would make it much easier to discover this. (Also, I have a database of previous recordings made outside of Myth and it would be handy for knowing what's already been recorded; that database will eventually be integrated into my version of Myth so such shows won't be rerecorded anyway, but for the moment being able to at least do this manually in mythweb would help a lot.) Note that I really am talking about the episode number, not the ID; yes, I know that it's often not present, but that's the most convenient number for me (it's short, it's human-meaningful, and my other database already uses it). I know that this info is displayed in the Program Details page in the actual frontend UI, but using the frontend's UI is fairly painful compared to mythweb with a real keyboard and a real high-resolution display at reading distance, instead of a remote control and the TV's output at viewing distance. If this isn't some option I'm missing, I'd be willing to patch my local copy of mythweb if someone could give me a pointer or two on where in it to look---and is this info in (or being considered for) the current SVN version? Thanks... ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Transcoding on a non myth machine
Date: Fri, 6 Jan 2006 00:13:03 -0500 (EST) From: Chris Pinkham [EMAIL PROTECTED] (a) The SBE's mythtranscode was getting handed myth:// URLs instead of just a pointer into the filesystem, then complained that it didn't support that mode. Jobs on the MBE ran fine, but that meant that some random proportion of them would just error out and die. In 0.18.x, the myth:// URLs are given if myth can't find the recording in the same directory path on the local backend as it is on the backend that recorded the file. In SVN, myth will also check the local backend's RecordFilePrefix directory for the file and use a local filename if it exists there, otherwise it falls back to the myth:// URL. Aha! So in other words, even though I can set the recording directory path on the SBE in its setup, if it's not exactly the same as on the master, transcoding fails. This is inconsistent with the way recording and commflagging work (the commflagger was working on my SBE, as far as I can tell), but I'll see if I can rearrange my NFS mounts so the SBE thinks /myth/tv is where recordings live (as the MBE thinks now), rather than thinking that they live in /mnt/mbe/tv or (via a symlink) /mnt/tv as they do now. Would a symlink on the SBE from /myth/tv to /mnt/tv (which will then traverse the mountpoint) be adequate, or are symlinks themselves going to be problematic? Incidentally, this particular arrangement was suggested by the linhes.html page on the KnoppMyth site, which talked about how to set up slaves; it's not clear to me how those instructions (which can only be talking about non-SVN versions) could possibly be right in the face of this transcoding inconsistency. (b) It then left all the errors in my job queue for some long period of time and nobody could figure out how to actually make them go away. (They appear to have all vanished 8 days (yes, not 7) after erroring, spontaneously; is there some week-and-a-day timeout somewhere?) This was apparent from reading the backend logs, since I've got both backends and the frontend logging to files to -v and have since about 6 weeks ago. I thought we went over this. Uh, if we did, it wasn't with me... :) The 8 days is because in 0.18.x, errors are kept around for 7 days and the cleanup job only runs once a day, so the jobs could be around for almost 8 days depending on when they ran and when the cleanup job ran in the housekeeper. In SVN, this has been shorted from 7 to 4. I think you could still have deleted these jobs from the mythfrontend status screen though by using the popup menu on an errored job. That seems logical, but nobody who said anything could -find- such a popup. I couldn't, and (IIRC) Jarod couldn't, either. (I recall something like, I could have -sworn- this existed, but I can't find it now...) My suspicion is that it went into SVN very shortly after 18.1, or something like that. (c) The resulting transcoded files had -VERY- low audio levels, and I couldn't find any way of making them at least match the originals. (My recordings in general -also- have low audio levels, despite setting ALSA mixer levels high; is there some way of convincing 250's and 350's to record louder? I'm comparing to the TV itself and all the other devices which share the cable feed, none of which have this problem.) There is a volume control for ivtv compatible cards right in the recording profile editor. This has been there since the ivtv support was added to Myth. Yeah, I know about that one. It's at 90%. IIRC, I also tried it at 100%, with not much effect. I should probably ask Hans and/or the ivtv lists if anyone has any ideas there; I'm almost wondering if the problem isn't ALSA but some register setting in the cards. (Is there some reason why all the sliders aren't 100% by default? Would there be distortion issues or something?) I could -live- with recordings being 6-12dB down from everything else (though the mystery annoys me), but what I can't deal with is the transcoded stuff being another ~12dB down from -that-. I had to peg the TV's volume almost to the very top to get listenable audio, and that's just wrong. (Not to mention dangerous if I select another input! :) It's not clear to me at all why transcoding should mess with any audio levels; does it even have any -inputs- for changing them? (E.g., is it looking at some ALSA slider for some weird reason? Does it have command-line args that affect this?) This was really easy to demonstrate, btw, since I told Myth not to toss the originals when it transcoded. I could just rename them back forth in place of each other and play them; the transcoded ones were always much quieter. ___ mythtv-users mailing list mythtv-users@mythtv.org
[mythtv-users] Transcoding on a non myth machine
It occurs to me that transcoded files play through the soundcard, whereas untranscoded ones play through the 350's outputs (and then through the soundcard). I wonder if there's some inconsistency there that's making transcoded files sound softer. I'll probably have to try playing some untranscoded files directly through mplayer, and then likewise with the transcoded ones; presumably then -both- cases will go through the ivtv framebuffer (and thus -only- out the soundcard w/o an intermediate step in the 350's outputs for the MPEG2 case), and that might tell me if it's really the case that the transcoded audio is quiet or there's some other step that's responsible. Btw, alsamixer reports that my master is at 71% (where it's been since I got the machine); I upped center to 100%, capture to 94%, and IEC958 to 100% at some point in the past to get some other levels to work better, but it hasn't helped the transcoding case much. (Even if my master is too low, -all- audio is looped through the soundcard, so you'd think it would make the untranscoded stuff just as soft, but it doesn't---MP2 is soft, but MP4 is much softer, and they -both- go through the master, I believe.) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Mythweb and episode numbers
Date: Thu, 05 Jan 2006 22:38:44 -0800 From: Chris Petersen [EMAIL PROTECTED] Done. I don't use the frontend for much other than watching an occasional show and cutting commercials -- didn't really know what the details page looked like and what info was available. Thanks! I assume it'd be fairly easy for me to look at the SVN patch and backport to 18.1? (SVN is too unstable for me, and I haven't yet looked carefully at how mythweb has changed between the two.) Anyway, next time please submit feature requests to http://svn.mythtv.org/trac/ ??? I'm confused. I was under the impression that feature requests were very much discouraged in trac unless they were accompanied by the code to implement them as well; I believe I read that somewhere on the main myth webpages that talk about how myth and trac are used. Am I misinformed? [*] (I recall something about feature requests in trac submitted without patches will be closed without notice or some such phrasing, which struck me as an awful idea, because it would mean that random devs couldn't just say, Hmmm, what quick hack has someone requested that I might work on?) I'd be very happy to submit feature requests to trac if I was wrong; I also have a bug report [1] on mythweb's bizarre handling of manual recordings in 18.1 that I'll submit to trac, since when I mentioned it on -users it got zero response; which made it difficult for me to know if it was already fixed in SVN and thus invalid as a report. And I thought I read somewhere that mythweb development was on hiatus; apparently I was wrong about that, too... :) I'd be ecstatic if I could punt the main UI (except for FF/REW/etc) in place of mythweb functionality completely, and with just a few improvements I think I could... [*] I can't actually find that text now, though in hunting around, I note that [2] has a bunch of wishes that seem like they might be fixed in SVN at least; I could prune it a bit if someone else would sanity-check the edits and check it back in. [1] http://www.gossamer-threads.com/lists/mythtv/users/164995 [2] http://www.mythtv.info/moin.cgi/UserWishList ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] LiveTV isn't flexible enough about its inputs
Date: Mon, 12 Dec 2005 20:50:27 -0500 From: Michael T. Dean [EMAIL PROTECTED] , but I haven't (yet) tested this thoroughly to see which way it works.) Would unchecking that option allow LiveTV to grab the appropriate input from any card, or is this just an architectural limitation of how 0.18.1's LiveTV is supposed to work? I'm pretty sure in 0.18.1 you have to explicitly change cards (and perhaps inputs) if a channel isn't available on the current. How exactly would I do that? After all, no matter which way the option is checked, it's basically up to Myth to choose which card is the one used when capturing input that's going to LiveTV. Is there some magic keystroke sequence that says, Change to card number n, and now change to card n's input m when in LiveTV? (And man, is that ever risky, because it requires someone using LiveTV to have an intimate knowledge of exactly which card(s) Myth is using [and planning to use] in order not to disrupt a recording.) Otherwise, the only way I see to do this is to put an extra input on my 350 and bring all composite inputs to that card, just 'cause it's the card being used for output, and that seems crazy. [Or is this what you actually meant, e.g., rearrange the hardware?] Architecturally, there seems to be no impediment grabbing input from any tuner and tossing it to any FE, and that would seem to apply for any input to any tuner. OTOH, I'd certainly believe it if there's some implementation limitation in 0.18.1 that makes this not work. In which case, I'll repeat my question: Does this sort of thing at least work in SVN? And is it truly an implementation restriction in 0.18.1, or is something misconfigured in my setup? Thanks... ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Is there any ordering dependency between transcodingand commflagging?
Date: Sat, 10 Dec 2005 23:37:01 -0700 From: Mike Grusin [EMAIL PROTECTED] I do the same thing; record in MP2 and transcode to MP4. I vaguely remember trying to comflag first and then transcode, and remember having some problems (perhaps it forget the comflag information?). Now I transcode THEN comflag, and things work perfectly. I'm new, so don't consider me an authoritative source. ;) How did you set it up such that transcoding happened first? My problem is that both try to run at once... :) (-And- that transcoding makes the audio very quiet, -and- that Myth chooses randomly which host to transcode on and then complains it can't cope if it chooses the slave backend, -and- that playing those transcoded files blows up mplayer and the window system along with it, -and- that transcoding errors leave entries in the job queue that nobody seems to know how to delete. So I'm probably going to turn transcoding off unless I can get solutions to any of these; I've mentioned them on this list, but nobody has suggested any possibilities...) All works very well for me here, using the above sequence. Maybe I'm just unlucky. I'll try recording some longer stuff and see how it goes. I auto-skip, but I don't destructively cut because there are rare times I want to check back during the commercial (for Next week on a very special E.R. mostly) that it's worth keeping things intact. What I'd like to know, is if there's an easy way to toggle auto-skip on and off while watching a recording? Rewinding into the commercial zone, you have to be very careful not to hit that first jump or it helpfully shuttles you around it again... Can't help you there, but I hope someone can. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Moving recordings onto DVD with subtitles
Date: Sun, 11 Dec 2005 11:20:05 + From: Piers Kittel [EMAIL PROTECTED] Hello all, As I'm deaf, I require to watch TV with subtitles - there's no choice for me really. Anyway, I'm using MythTV taken from SVN only so I can have subtitle support which 0.18.1 doesn't have. My hard drive is filling with programs I want to keep, and I want to transfer it to video DVD but I want to peserve the subtitles - i.e. I can put it in my bog standard DVD player, start playing and select English Subtitles and it works. How can I do this if it's any way possible? If selection is not possible, is it possible to paste subtitles on the screen making open captions, and if this isn't possible, what are my options? I have half of a possible solution for you, thanks to Hui Zhou's little utility which I recently discovered while trolling the archives of the ivtv-devel list. Grab http://www.wam.umd.edu/~zhouhui/vbiutil-20050928.tar.gz This tool produces timestamped ASCII text of the closed captioning, suitable for input via the -sub switch for mplayer (assuming you've made sure mplayer has OSD fonts and so forth). It requires the CC data written to the stream by the PVR-x50 hardware encoders, and will -not- work if you've transcoded the streams (because mythtranscode doesn't support CC data and throws it away). It's three small programs and a readme that tells you how to use them. I don't know if any DVD-authoring software can take such a list (or such a list after being filtered through some trivial perl script to change its syntax) and produce new subtitling, but maybe someone else does. An alternative (which would mean giving up on using a standalone DVD -player- per se, and using a DVD drive in a computer instead) would be to keep both the original MEGP2 stream around, and the text file produced by the utility above (which is tiny---on the order of 20-30K per hour, and of course you could gzip it if you cared), and write both files to a DVD as normal data files. Then, to play them, use mplayer -sub cc.txt program.mpeg2 (approximately) and play the data directly off the DVD that way. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Moving recordings onto DVD with subtitles
Date: Sun, 11 Dec 2005 11:20:05 + From: Piers Kittel [EMAIL PROTECTED] Hello all, As I'm deaf, I require to watch TV with subtitles - there's no choice for me really. Anyway, I'm using MythTV taken from SVN only so I can have subtitle support which 0.18.1 doesn't have. My hard drive is filling with programs I want to keep, and I want to transfer it to video DVD but I want to peserve the subtitles - i.e. I can put it in my bog standard DVD player, start playing and select English Subtitles and it works. How can I do this if it's any way possible? If selection is not possible, is it possible to paste subtitles on the screen making open captions, and if this isn't possible, what are my options? One more piece of this---if you're going with the solution of just dumping the CC into a file using Hui Zhou's utility, you don't necessarily have to use the SVN MythTV. I'm using 0.18.1, in which the UI checkbox to enable subtitling doesn't work with ivtv 0.4.0 or 0.4.1 (I'm using both on various machines), but you can enable it yourself by calling ivtvctl -b wss,cc -x 1 -d /dev/video0 for each of video0, 1, ... that you may have capturing video, and by calling ivtvctl -w wss,cc -d /dev/video0 for each card you have displaying video (e.g., a -350 that you use for capturing and display should have both lines, and a -250 should have only the first). This needs to be enabled once per boot; I just put the appropriate lines in /etc/init.d/mythbackend after it starts mythbackend itself. (If you do this, note that, in my distro at least, ivtvctl lives in /usr/local/bin/, but the default path for init scripts doesn't include that directory, so you may have to write /usr/local/bin/ivtvctl instead.) I don't know if capturing CC data works at all in ivtv releases prior to 0.4.0, so I'd recommend upgrading to there if you try this in an earlier release and it doesn't work. (Don't upgrade until you try it, of course---no point possibly going through the hassle of upgrading and maybe breaking a working configuration if the current one works well enough...) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] mythtranscode output causes my mplayer to explode
In 0.18.1, in Ubuntu Breezy: I've just discovered that mythtranscode is producing files that cause my mplayer to explode. (I'm running mplayer on my frontend right over the display being produced by mythfrontend on the PVR-350 there; the explosion apparently nukes the entire login session, because as soon as mplayer blows up, I wind up staring at Ubuntu's login screen. It's not -just- nuking mythfrontend, because I set up mythtv's .xsession to respawn mythfrontend every time it terminates.) These files start out MPEG2 from a PVR-250, and I'm transcoding with all the default options. (I've set everything to 720x480, but nothing else has been changed---not bitrate or anything like that.) Note also that mplayer first complains that these files have no audio. It then displays several seconds (5-10) of video, and then blows up. This has happened on at least two files so far. I know that not -all- transcoded files do this, because when I first tried this, it worked enough to at least give me a file with very -quiet- audio (which I bugreported here but which no one has responded to), whereas now I seem to be getting files that claim no audio at all. I'm not deleting the original MPEG2's; playing those is perfect. Anyone have any clues? Tnx. [EMAIL PROTECTED]:/mnt/mbe/tv$ mplayer -vo xv -framedrop 1002_20051208003500_20051208004000.nuv MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team CPU: Advanced Micro Devices Athlon MP/XP/XP-M Barton (Family: 6, Stepping: 0) Detected cache-line size is 64 bytes MMX2 supported but disabled SSE supported but disabled 3DNow supported but disabled 3DNowExt supported but disabled CPUflags: MMX: 1 MMX2: 0 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0 Compiled for x86 CPU with extensions: MMX 86 audio 200 video codecs Linux RTC init error in ioctl (rtc_irqp_set 1024): Permission denied Try adding echo 1024 /proc/sys/dev/rtc/max-user-freq to your system startup scripts. Opening joystick device /dev/input/js0 Can't open joystick device /dev/input/js0 : No such file or directory Can't init input joystick Setting up LIRC support... Playing 1002_20051208003500_20051208004000.nuv. Cache fill: 0.00% (0 bytes)MPEG4-ES file format detected. FPS seems to be: 302727/1 vo: X11 running at 720x480 with depth 24 and 32 bpp (:0.0 = local display) == Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffodivx] vfm:ffmpeg (FFmpeg MPEG-4) == Audio: no sound Starting playback... VDec: vo config request - 720 x 480 (preferred csp: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.50:1 - prescaling to correct movie aspect. VO: [xv] 720x480 = 720x480 Planar YV12 aspect: Warning: no suitable new res found! aspect: Warning: no suitable new res found! aspect: Warning: no suitable new res found! Marker bit missing before time_increment_resolution Marker bit missing before fixed_vop_rate [mpeg4 @ 0x865fbd0]Complexity estimation not supported [mpeg4 @ 0x865fbd0]header damaged Error while decoding frame! Marker bit missing before vop_coded47% Marker bit missing before vop_coded VDec: vo config request - 1753 x 6557 (preferred csp: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.50:1 - prescaling to correct movie aspect. VO: [xv] 1753x6557 = 9836x6557 Planar YV12 aspect: Warning: no suitable new res found! aspect: Warning: no suitable new res found! aspect: Warning: no suitable new res found! vf.c: have to REALLOCATE buffer memory :( [mpeg4 @ 0x865fbd0]warning: first frame is no keyframe vf.c: have to REALLOCATE buffer memory :( [mpeg4 @ 0x865fbd0]marker does not match f_code [mpeg4 @ 0x865fbd0]marker does not match f_code [mpeg4 @ 0x865fbd0]marker does not match f_code [mpeg4 @ 0x865fbd0]marker does not match f_code [mpeg4 @ 0x865fbd0]concealing 45100 DC, 45100 AC, 44892 MV errors aspect: Warning: no suitable new res found! Marker bit missing before vop_coded47% Marker bit missing before vop_coded47% [mpeg4 @ 0x865fbd0]marker does not match f_code [mpeg4 @ 0x865fbd0]marker does not match f_code [mpeg4 @ 0x865fbd0]marker does not match f_code [mpeg4 @ 0x865fbd0]concealing 45100 DC, 45100 AC, 41833 MV errors [EMAIL PROTECTED]:/mnt/mbe/tv$ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] How do I get rid of old erring jobs?
In 0.18.1: Since I've been experimenting with transcoding, I've built up a couple dozen jobs that mythweb all claims to be in Errored state. Some of these are more than a week old. Not only is this annoying to see there, but running mythbackend -v all is getting tedious, since it mentions 60-odd old jobs every single iteration (currently ten seconds since I have the job queue set to check frequently). How do I make these go away? Shouldn't they have gone away on their own? ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] How do I get rid of old erring jobs?
Date: Sat, 10 Dec 2005 00:34:56 -0800 From: Jarod Wilson [EMAIL PROTECTED] On Saturday 10 December 2005 00:19, [EMAIL PROTECTED] wrote: In 0.18.1: Since I've been experimenting with transcoding, I've built up a couple dozen jobs that mythweb all claims to be in Errored state. Some of these are more than a week old. Not only is this annoying to see there, but running mythbackend -v all is getting tedious, since it mentions 60-odd old jobs every single iteration (currently ten seconds since I have the job queue set to check frequently). How do I make these go away? Shouldn't they have gone away on their own? Assuming I'm understanding the situation right, you should be able to go ino the frontend - Info - Job Queue, you can select jobs and delete them there. Err, well, almost. I can -see- them there, but I have no idea how to delete them. I don't know what event name I should use to map to a button on my remote, so I tried running mythfrontend in an X window on a machine with a keyboard attached to it, but of -course- ? doesn't show any self-documentation, and none of mMdD do anything, and I can't seem to find anything on the web documenting what valid commands might exist in this window, so I'm still stumped. Any ideas? If I navigate into that window with rightarrow, I can scroll up down over the jobs, and hitting Enter on one gives me a menu that says Requeue Job? with choices of Yes and No. But I sure don't see a choice to -delete- the job... Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] LiveTV isn't flexible enough about its inputs
In 0.18.1: [Is this fixed in SVN, given its complete rearchitecture of how LiveTV works? I'm not running SVN, so I can't easily check.] I've got a PVR-350 on an SBE/FE, and some PVR-250's on the MBE. One of the 250's has a composite input hooked to a cable box; all of the x50's have the same RF signal going to them as well. I defined the 350 on the SBE last, precisely so that its input would have lowest priority. If I use LiveTV on an RF channel, the 350's RF input is selected and all is well. But if I try for a channel going to the 250's composite input, LiveTV just gives me a blank screen, with no explanation of what's going on. Meanwhile, my backend logs this: 2005-12-09 19:25:43.794 Failed to find channel(201) on current input (Tuner 0) of card (6). 2005-12-09 19:25:43.795 Failed to find channel(201) on any input of card (6). 2005-12-09 19:25:43.795 1 0 Well, duh, sure, that card doesn't -have- anything attached to its composite input. I expected that LiveTV would have picked a card that -does- have that channel and streamed video from it, crossing a network boundary if necessary (e.g., if the FE wasn't on the same machine that had the relevant card, which in this case it ain't). I -do- have avoid conflicts with recordings checked, and I'm reluctant to uncheck it since I'd rather that LiveTV not step on a recording. (Though if -all- that button does is to change the priority of which card gets used for what, it's not doing what I'd expect---what I'd -want- it to do is to say, If all tuners are currently in use for recording and you want LiveTV, warn me so I don't ruin a recording and likewise grab LiveTV away from me if you need all tuners for recording while I'm watching live, but I haven't (yet) tested this thoroughly to see which way it works.) Would unchecking that option allow LiveTV to grab the appropriate input from any card, or is this just an architectural limitation of how 0.18.1's LiveTV is supposed to work? (And does SVN overcome this limitation?) Thanks... ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] How do I get rid of old erring jobs?
Date: Sat, 10 Dec 2005 09:04:46 -0800 From: Jarod Wilson [EMAIL PROTECTED] I seem to recall either the select or menu button on my remote popping a dialog that let me delete jobs. Of course, now I try that just now, looking at some jobs that recently ran to completion, and all I get is the requeue choices. Odd. It was just a few days ago that a job that didn't run successfully was sitting in there, and one of the menu choices was to delete the job... Are you running 0.18.1 or SVN? (I'm running 0.18.1.) In my particular case, the menu button on my remote isn't mapped to any action at all on that particular page, and its OK butten (basically Enter/Select) pops up the Requeue menu. I've tried a few other buttons at random, but I'm reluctant to try them all, since who knows -what- might happen... I find it really, really irritating that the Myth UI has no keystroke self-documentation in it at all, and wish that this was a development priority---it would save a lot of dumb questions (like mine here) to the list and elsewhere. As far as I know, the only way (without grovelling through all the sources) to figure out what actions exist is to look at the keymapping page of mythweb, which is itself obscure and might not even be installed, and probably isn't complete---my mythweb only lists 3 different contexts, and I'll bet there are more, but I'd probably have to inspect the database to figure that out or what they're called (and then maybe modify mythweb to display them). The -right- thing would be to, by default, have some HELP action that is (by default) mapped to the -same- key on the keyboard in -every- page, and which could (by default, with appropriate LIRC entries) be mapped to the -same- key on the remote in -every- page. Then it would be totally trivial for someone to say, What can I do here, and what keys will do it for me? Sure, it'd be hard to backtranslate action names to key names in the presence of LIRC, but at least it would tell you what the keyboard could do, and at least it would tell you what you -might- want to define in your lircrc to go in the forward direction. But I bet that trying to raise the usability issue again won't do much. For the moment, unless somebody can figure out how this is mapped, I may have to resort to doing surgery on my database to get these jobs to go away. That's dangerous for a whole number of reasons. (For starters, once I find them in one table, I'm not sure if other things in other tables will depend on them being there, so it means I'll have to read the code to figure out how job deletion is supposed to work in general. Surely there's a better way... :) Thanks for any help anyone can provide. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Re: Strange MythBackend troubles
Date: Fri, 9 Dec 2005 16:58:53 -0800 From: Jeff Clemens [EMAIL PROTECTED] I think I figured out the remote system problem. I wasn't aware that you don't need to run a database on the remote system. Once I turned that off, and re set everything up between the master and slave boxes, the delete problem, and the inability to jump forward and back cleared up. So in other words, mysql is no longer running on your slave backend at all? (My SBE [which is also my FE] has mysql still running; it hadn't occurred to me that this is a problem, and in fact I thought that certain SBE/FE settings were stored locally. Where -is- this info stored? Should I disable mysql on my SBE/FE, too? I should point out that I have no problems deleting things...) Now, I have a different problem, though. The tuner on the slave backend shows as 'not available' in system status. Any ideas there? both master and slave backends are running. nothing is recording, it's just 'not available' If I boot my MBE, my SBE/FE always claims that its tuner is not available unless I boot the SBE. I bug-reported this dependency a few weeks ago on this list but it generated no response (except, well, just restart mythbackend on the SBE instead of any idea of whether this was even viewed as a bug at all). This means I have to be careful to boot my SBE only after my MBE is actually up, which complicates recovery from power failures (of which I just had one today, actually), and especially unattended recovery. [And after booting the MBE without rebooting the SBE, certain UI operations work, but some complain that the backend has gone away; if I just okay that popup and continue, the SBE/FE recovers and notices that the MBE is there. But the SBE's tuner is permanently unavailable unless the SBE is restarted.] So have you tried rebooting your SBE and/or restarting mythfrontend? Does this help? P.S. This is all in 0.18.1, not SVN. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] PVR-250 composite-in gives black video---why?
Date: Fri, 9 Dec 2005 11:00:43 + From: Nick [EMAIL PROTECTED] Also, when setting up a PVR-x50, the correct input (S-Video or composite) is not always necessarily #0 for the first card. Indeed; it seems that on my -250's, the card's built-in input is Composite 4 in myth, and the add-on input with the A/V cable kit is Composite 1. Go figure. (Inputs 0, 2, and 3 appear unused. I'd like to know what the Hauppauge engineers are smoking.) Tnx. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Re: Strange MythBackend troubles
Date: Fri, 9 Dec 2005 21:39:47 -0500 From: Sasha Z [EMAIL PROTECTED] Are you sure you guys aren't experiencing the same problems as I am in this thread? http://www.gossamer-threads.com/lists/mythtv/users/164194 Well, I don't think -I- am. The only time I've noticed that the SBE/FE can't talk to the MBE is after I've rebooted the MBE, and that situation clears up for the FE as soon as I've acknowledged the popup that there's a problem. (That popup can come at irritating times, though---like -after- I've already entered all the information for a manual schedule, whereupon it drops all that info on the floor as soon as I've cleared the condition and leaves me with the default page again.) OTOH, the SBE's tuner is permanently unavailable until I reboot the SBE. So this doesn't seem to be the same randomly goes away problem that you're reporting. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users][OT] - How grab VHS tapes?
Date: Wed, 7 Dec 2005 09:32:10 -0700 From: Dave Packham [EMAIL PROTECTED] Any way to detect good signal? I have seen a lot of software that will stop capture on BAD signal or snow Can you be more specific about this? I asked a few days ago if anyone had any ideas on how to detect this inside an mpeg, which is half of trying to get myth to autoreschedule recordings that went bad because the studio screwed up or some other hardware issue happened, but I haven't heard any good ideas and will probably start hunting around in the video-processing and image recognition arenas otherwise... Tnx. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Very low audio level after transcoding
[Should I move this to the -dev list? This seems like a bug, and nobody here has said anything about it yet I'll move it to -dev and/or just open up a ticket if I don't hear anything.] Note: I found the Volume % slider in Transcode-MPEG2-Audio Quality and changed it from 90% to 100%. It -might- have made a slight difference; it'll be hard to tell without more testing. But it certainly didn't make -enough- of a difference. Also: the self-documentation for that slider claims Recording volume of the capture card. Is that -really- what it's there for? If so, why? In that case, since my capture card is at 90%, it seems that setting the slider to 100% might be going in the wrong direction, and maybe I should lie to it and say, e.g., that my capture card was at 50% so transcoding might boost the volume. But this is backwards and certainly not how -I- would design the control---how's it -really- supposed to work? Thanks! Date: Wed, 7 Dec 2005 02:06:39 -0500 (EST) From: [EMAIL PROTECTED] In 0.18.1: I'm experimenting with transcoding from MPEG2 to MPEG4, and have discovered that the transcoded files have very low audio levels; I'd guess on the order of 6-9dB down from the source, at least. Where are these levels specified? I'm quite surprised that they're affected at all. I'm using all the defaults (as far as I know) except that I changed the transcoding dimensions from 480x480 to 720x480 to match the original from the PVR-250. I can verify absolutely that it's the transcoding process that's doing this, because I'm saving the originals. If I play the transcoded file, and then rename that file to some temporary name and rename the .nuv.old file in place of the original and play -that-, audio is back at its normal level. If I undo the renaming, audio is again quiet. This is true for transcodings from 5 different channels. According to ps, the actual transcoding process was something like: mythtranscode -V 4099 -c 1002 -s 2005-12-06T21:35:00 -p autodetect -d ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Problems in load-balancing commflagging
[Should I move this to -dev and/or open a ticket? I think I found a bug. Is there any point to bug-reporting 0.18.1, since SVN has diverged so far from it at this point?] I have new data. But I'd still -really- love it if somebody, anybody could answer any subset of the questions at the very bottom of this message, since I'm still mostly buffaloed by this whole thing. Thanks! (And I've annotated some of 'em with my new understanding, so really there are only a couple I'm really confused about...) First off, I realized that I never ran mythtv-setup on my SBE to change the job queue limit -there-; it was still at 1. I've since changed it to 5, the current max unless I recompile, and I've also reset the job check frequency there to 10s to match the MBE. Next, I ran both backends (slave and master), and the frontend, with -v all and am dumping the output into three different files. I then tried another run recording 2.3,4,5,6,7 simultaneously. It appears that the reason (or at least -one- reason) mythtranscode is erroring is because most of the jobs running it are being attempted on the SBE (probably because the MBE is busy with 5 commflagging jobs and 1 more queued---which won't run 'cause of the 5-job limit), -and- that mythtranscode incorrectly believes it can't run on an SBE! Instead, I see lines like this in the backend log on the SBE (I didn't see them last time because I was only running the MBE backend with -v): 2005-12-07 22:15:45.360 Attempted to transcode myth://192.168.0.20:6543/1002_20051207221000_20051207221500.nuv. Mythtranscode is currently unable to transcode remote files. Yet this is (probably!) bogus because the slave has the master's recordings NFS-mounted anyway, and mythcommflag certainly has no trouble looking at that filesystem. It looks like mythtranscode is asking the database for the filename, getting back something with this myth:// access path instead, and punting. What it -should- be getting back is just a filename that points into /myth/tv, which is NFS-mounted and corresponds to the same directory with the same pathname on the MBE. Curiously, I see a different number of these failures for each channel; this might be related to when they started (since they started at least 10s apart from each other, but all 6 recordings started and ended simultaneously. Here's the complete log of just those lines: 2005-12-07 22:15:45.360 Attempted to transcode myth://192.168.0.20:6543/1002_20051207221000_20051207221500.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:15:45.480 Attempted to transcode myth://192.168.0.20:6543/1002_20051207221000_20051207221500.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:15:45.598 Attempted to transcode myth://192.168.0.20:6543/1002_20051207221000_20051207221500.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:15:45.719 Attempted to transcode myth://192.168.0.20:6543/1002_20051207221000_20051207221500.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:30:45.341 Attempted to transcode myth://192.168.0.20:6543/1002_20051207222500_20051207223000.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:30:45.461 Attempted to transcode myth://192.168.0.20:6543/1002_20051207222500_20051207223000.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:30:45.581 Attempted to transcode myth://192.168.0.20:6543/1002_20051207222500_20051207223000.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:30:45.699 Attempted to transcode myth://192.168.0.20:6543/1002_20051207222500_20051207223000.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:31:45.339 Attempted to transcode myth://192.168.0.20:6543/1003_20051207222500_20051207223000.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:31:45.459 Attempted to transcode myth://192.168.0.20:6543/1003_20051207222500_20051207223000.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:31:45.579 Attempted to transcode myth://192.168.0.20:6543/1003_20051207222500_20051207223000.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:31:45.699 Attempted to transcode myth://192.168.0.20:6543/1003_20051207222500_20051207223000.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:32:45.371 Attempted to transcode myth://192.168.0.20:6543/1004_20051207222500_20051207223000.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:32:45.491 Attempted to transcode myth://192.168.0.20:6543/1004_20051207222500_20051207223000.nuv. Mythtranscode is currently unable to transcode remote files. 2005-12-07 22:32:45.610 Attempted to transcode myth://192.168.0.20:6543/1004_20051207222500_20051207223000.nuv. Mythtranscode is currently unable to transcode
[mythtv-users] Is there any ordering dependency between transcoding and commflagging?
In 0.18.1: I'd like to do commflagging and transcoding from MEGP2-MPEG4. I was originally thinking that I needed to commflag first, then transcode, but the behavior of Myth when I try (it does both at once, or tries to), makes me wonder if I need to worry about this ordering at all. So does commflagging care if it flags an MPEG2 stream but then gets used on an MPEG4 stream? Is its cutlist still going to be as accurate? Is it more efficient to run it on one kind of file or the other? Or should I not care and just let both happen on the same file at the same time and everything will just work fine? Thanks... P.S. Note that I'm -not- automatically cutting during the transcode, and probably won't unless I have more assurance that commflagging is accurate for the things I'm recording (and it seems way wrong for a lot of the US network shows I've tried it on, which is interesting--- I'm using All for its settings and I'm surprised its performance seems so haphazard given that everyone else seems to have no problems with it...). So since I'm not automatically cutting, it's not going to save any transcoding time if I commflag first, for instance. Tnx. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Problems transcoding
In 1.18.1: I'm having problems transcoding. I've got an MBE/SBE setup with several 250's in the BE and one 350 in the SBE/FE. Commflagging is set to begin immediately upon episode start. I've been trying to see how I like MPEG4 transcoding from the MPEG2 being produced by the 250's, but I can't seem to get the transcoder to run at all. I changed the Default recording group to automatically transcode after recording, changed it to 720x480 from the default 480x480, and left everything else alone (including MPEG-2 PS; what are the definitions of the various types in this field, and which should I be using?). If I schedule a recording, it -appears- (from the mythweb status page) that transcoding starts -immediately-, e.g., even before commflagging is finished, even though I don't have transcode before commflagging checked. The status page also says Errored about the transcoding job, but I can't figure out where any of this might really be logged (not in mythweb, and not in any logs I can find), so I can't debug -why- it's errored. Also, according to mythweb, the transcoder ran on the SBE, even though the commflagger ran on the MBE. This is okayh with me (especially since I can't seem to get the commflagging to loadbalance; that'll be my next mesage), but only if the transcoder actually -works-. But is the transcoder running on the SBE somehow contributing to the problem? (Note that the SBE and MBE share the same recordings directory via NFS.) [FWIW, I also have the button checked to preserve the original recordings after transcoding, since I'd like to A/B compare them.] I then tried going to the Transcoder-From MPEG2 menu item, changed its resolution, and left everything else alone. (It looks like various checkboxes for things like interlacing so forth should probably get set, but I haven't touched them for the moment until I can see -anything- from transcoding.) It didn't change the behavior. Again, which of these am I -supposed- to be setting---the one in the various recording profiles, or the ones in the Transcoders group? The doc on this is -very- thin on the ground, and it's totally obscured by zillions of random google hits about transcoding that aren't helping. Thanks... ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Problems in load-balancing commflagging
In 1.18.1: I'm trying to figure out if I can load-balance commflagging. I've got an MBE/SBE setup with 5 250's in the BE and one 350 in the SBE/FE. Commflagging is set to begin immediately upon episode start. I'd like to run commflagging as soon as possible, in parallel as much as possible, since it appears that I can easily run 5-6 jobs on even one of my hosts without really saturating it. (Well, 5 commflaggers saturate the CPU, but not the disk, and I see no skipping in the recordings being made while this happens.) However, I've got some problems: (a) The setup page that deals with running jobs tops out at 5, e.g., I can't tell myth to schedule more than 5 jobs in parallel because the control just won't go any higher. Why's it got this limit? (The jobs also started 1 minute apart, so doing 5-minute test recordings meand that the 5th job didn't evne start until the recordings were over, so I set the time to check between jobs from 60 seconds down to 10. I'd be happy if that could be set down to 1, if it didn't cause Myth to thrash, or, even better, if it was smart enough to start -all eligible jobs at once- in each sweep---then I could leave it at the default 60s, but all commflagging jobs would be started simultaneously, one per simultaneous recording.) (b) Possibly because of (a), if I do a test recording of 6 things simultaneously, commflagging only happens on 5 of them at once. The 6th waits until the others are done, and then runs. They all run on the MBE, even though I don't have run jobs only on original recording host set, but OTOH, there's that cap of 5 jobs total, so would I ever see that sixth job on the SBE? What I'd -like- to see happen is for all 6 jobs to run at once. Even if 5 of them run on the MBE and one runs on the SBE, that's actually okay with me, because I can probably soak up the remaining CPU on the SBE doing transcoding from MPEG2 to MPEG4, but to do this requires that I have a lot of jobs running. (I don't know if transcoding will count against the 5-job limit I see or not, since I haven't yet managed to get transcoding to run at all; see previous message.) An even cleverer thing (but which I wouldn't be surprised can't happen in the current Myth architecture) would be to load-balance the commflagging, so that (if I'm recording with 6 tuners), 3 of them happen on the MBE, and 3 happen on the SBE. Myth would have to be reasonably intelligent in its job-scheduling for this to work, though. And it still might make sense to try to push as many of them on the MBE as possible, since commflagging can't happen -faster- than real-time anyway for recordings in progress, and this would leave the SBE free to be the transcoding engine. Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Problems in load-balancing commflagging
Date: Tue, 6 Dec 2005 19:02:09 -0500 (EST) From: Chris Pinkham [EMAIL PROTECTED] (a) The setup page that deals with running jobs tops out at 5, e.g., I can't tell myth to schedule more than 5 jobs in parallel because the control just won't go any higher. Why's it got this limit? The Max of 5 simultaneous jobs (per backend) was set prior to the creation of realtime flagging. With realtime flagging and hardware encoding cards I can see how someone might want more than 5 jobs running at a time on a host. I've bumped this number up to 10 in my source tree so it'll be in SVN with my next commit. Ok. (I'm running 1.18.1 'cause SVN is way too unstable for me, but I might be willing to try recompiling from 1.81.1 sources if enough things accumulate that it seems worthwhile. Which file defines that parameter?) The default check frequency is 60 seconds, but it goes down to 10 or up to 300 seconds in 5-second increments. I don't think 10 seconds is too long to wait for a queue run, but don't see harm in setting this as low as 5 seconds. Going all the way to 1 could cause problems for some people though for a couple reasons. The constant database hits querying for new jobs and the added system load from firing off 5-10 jobs at 1-second intervals could cause hickups in recording so I didn't want to go that low. I also didn't want to fire off multiple jobs in the same cycle because that would have the same effect. Thinking about it now, I can see a alternative in the middle though. I could make it so that the JobQueue sleeps for JobQueueCheckFrequency seconds in between runs normally, but when it fires off a job, it could be modified to only sleep for 5 or 10 seconds so it could pickup another job quicker. That would certainly work, and I agree there's no point going lower than 10 seconds or so if it'll cause glitches. I'll leave mine at 10s for the moment. (b) Possibly because of (a), if I do a test recording of 6 things simultaneously, commflagging only happens on 5 of them at once. The 6th waits until the others are done, and then runs. They all run on the MBE, even though I don't have run jobs only on original recording host set, but OTOH, there's that cap of 5 jobs total, so would I ever see that sixth job on the SBE? One of them should have run on the SBE as long as you have the SBE configured to allow running flagging jobs. Turn on JobQueue debugging with -v jobqueue on the backend to see if it tells you why it isn't firing off the 6th job on the SBE. With -v jobqueue enabled, it prints out information about every job everytime through the loop so you can see what's running, what's queued, what's finished, etc.. I tried this, and -everything- changed. More in next message. An even cleverer thing (but which I wouldn't be surprised can't happen in the current Myth architecture) would be to load-balance the commflagging, so that (if I'm recording with 6 tuners), 3 of them happen on the MBE, and 3 happen on the SBE. Myth would have to be reasonably intelligent This is on my TODO list, but I haven't sat down and looked at it much because it hasn't been that high of a priority. I'd like to make it so that the Queue could prefer a less-busy backend (based on number of items recording and jobs running). I have a few other things on my list to help improve it as well such as creating a concept of a rush job so if you start watching a recording that isn't flagged it could queue a flagging job and push it to the head of the queue and wakeup the sleeping ProcessQueue thread. That's a cute idea. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Problems in load-balancing commflagging
Date: Tue, 6 Dec 2005 19:02:09 -0500 (EST) From: Chris Pinkham [EMAIL PROTECTED] (b) Possibly because of (a), if I do a test recording of 6 things simultaneously, commflagging only happens on 5 of them at once. The 6th waits until the others are done, and then runs. They all run on the MBE, even though I don't have run jobs only on original recording host set, but OTOH, there's that cap of 5 jobs total, so would I ever see that sixth job on the SBE? One of them should have run on the SBE as long as you have the SBE configured to allow running flagging jobs. Turn on JobQueue debugging with -v jobqueue on the backend to see if it tells you why it isn't firing off the 6th job on the SBE. With -v jobqueue enabled, it prints out information about every job everytime through the loop so you can see what's running, what's queued, what's finished, etc.. Things are now broken in a different way. I have many questions. I tried running mythbackend -d -v jobqueue (as the mythtv user) on the MBE, and got -very- different results than I was getting before; I suspect that this is because I hadn't restarted mythbackend since trying to turn on transcoding. (It's been booted -many- times since setting up commflagging, but that was in previous weeks.) Do changes to transcoding and/or recording profiles only take effect on restart of the backend? I didn't -think- so (and it'd be pretty inconvenient if it always took a backend restart to change this sort of thing) but I haven't done anything else to the box My test environment was to start recording on channels 2,3,4,5,6,7 simultaneously for 5 minutes via manual scheduling. The -previous- behavior (before I restarted mythbackend this evening with -v jobqueue was to do all commflagging on the MBE, with the first 5 jobs running in parallel, and the sixth running (I think!) on the MBE as well (coulda been the SBE; I might not have noticed if it was), but definitely after the first five. Transcoding errored out and didn't run at all. -Now- what happens is the following: (a) The instant recording was due to commence, the backend logged a bunch of Skipping Flag Commercials job for chanid 1002 @ 20051206213500, should be run on 'sbe' instead; it logged one of these page channel I'd scheduled (with appropriate chanid's, of course). I have no idea why the MBE (which has 5 of the 6 tuners) is suddenly claiming that the SBE should be running commflagging instead of the MBE. No commflagging jobs ever ran on the MBE, as far as I could tell by running ps -elf | grep comm a lot. (b) One commflagging job started up on the SBE. When it finished, another started, and so forth---no parallelism. (c) Five transcoding jobs started up on the MBE, in parallel, as soon as recording finished. (Before, -no- transcoding job were starting.) (d) The sixth transcoding job claimed an errored state instead of doing anything. I can't -guarantee- that was the job that corresponded to the recording on the SBE's tuner, but I'm suspicious that it might have been, since it was channel 7 and they might have been allocated to tuners in the order in which I created the schedules. [select * from mythlog isn't telling me what tuner recorded what; is there some better way to find out?] So, my still-unanswered questions: (a) How do I debug this better? If a job claimed errored, how do I grab ahold of its diagnostic output so I can see -why- it errored? (b) What's going on w/the job queues here? (c) Transcoding was supposed to start -after- commflagging, but it didn't. Why not? (d) Why did 1 out of 6 transcoding jobs get an error, and what exactly -was- the error? (e) There are at least two places to turn on transcoding---one is in the various profiles for Default, LiveTV, High, and Low, and one is in the Transcoding-MPEG2 slot one menu page away. Which of these -should- I turn on, and which -shouldn't- I? (Right now, they're -both- on, because turning on the Default one didn't do anything when I tried it; see previous message about that.) (f) Is MPEG2-PS the right thing in that menu, or should it be TS, or is it something else entirely? Where are these choices documented? (g) Why is the diagnostic output from mythbackend mentioning that it's studiously ignoring a bunch of commflagging jobs from two days ago? (That's the last time I tried to record anything.) -Those- jobs ran okay, incidentally, and on the MBE. It's also mentioning the two Errored transcoding jobs I tried to run that day when I was trying to debug transcoding. Why are they still hanging around in the job queue? What makes them go away? (h) What other options does mythbackend take, and what do they do? (I note that it has no manpage.) Thanks! ___ mythtv-users mailing list
[mythtv-users] Problems in load-balancing commflagging
Date: Tue, 6 Dec 2005 23:18:02 -0500 (EST) From: Chris Pinkham [EMAIL PROTECTED] The Max of 5 simultaneous jobs (per backend) was set prior to the creation of realtime flagging. With realtime flagging and hardware might be willing to try recompiling from 1.81.1 sources if enough things accumulate that it seems worthwhile. Which file defines that parameter?) mythtv/setup/backendsettings.cpp Search for JobQueueMaxSimultaneousJobs. There are 3 numbers on the line where the HostSpinBox is declared. The first is the minimum (needs to stay at = 1), the second is the max, and the third is the step increment. Thanks! I'll add this to my queue of things to change if I decide to recompile 1.18.1. (I wish SVN wasn't protocol-incompatible with the stable release, and that SVN had dangerous work done out on a branch instead of on the mainline; if those two things weren't true, I could afford to at least see if some of these issues might be fixed there, but with the current situation, I'd need two dedicate a pair of machines just to SVN if I also wanted to make sure I had a setup that worked reliably enough to actually record with while also making sure the new configuration worked, and I just don't have that much spare hardware... :) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Problems in load-balancing commflagging
Date: Tue, 6 Dec 2005 23:42:00 -0500 (EST) From: [EMAIL PROTECTED] -Now- what happens is the following: (a) The instant recording was due to commence, the backend logged a bunch of Skipping Flag Commercials job for chanid 1002 @ 20051206213500, should be run on 'sbe' instead; it logged one of these page channel I'd scheduled (with appropriate chanid's, of course). Whoops, I misspoke: 10 seconds after recording started (e.g., the next time my every-10s job queue got checked), I got the Skipping messages, -and- I -also- got one of Found Flag Commercials job for chanid 1002 @ 20051206213500 in Running state and 5 of Found Flag Commercials job for chanid 100x @ 20051206213500 in Queued state, for x in 2,3,4,5,6,7 (yes, including 7, despite the later error running that job). That sort of thing persisted for each later iteration. Each iteration -also- said Currently Running 0 jobs., which makes no sense. 3 different sets of logging output are below, to try to make sense of all this. Here's the backend just after I started it: 2005-12-06 21:22:39.727 New DB connection, total: 1 Starting up as the master server. 2005-12-06 21:22:39.747 New DB connection, total: 2 2005-12-06 21:22:39.748 mythbackend: MythBackend started as master server 2005-12-06 21:22:39.755 New DB connection, total: 3 2005-12-06 21:22:40.710 New DB scheduler connection 2005-12-06 21:22:40.713 JobQueue::RecoverQueue: Checking for unfinished jobs to recover. 2005-12-06 21:22:40.714 mythbackend version: 0.18.1.20050510-1 www.mythtv.org 2005-12-06 21:22:40.714 Enabled verbose msgs : important general jobqueue 2005-12-06 21:22:40.718 JobQueue::GetJobsInQueue: findJobs search bitmask 4, found 10 total jobs 2005-12-06 21:22:40.719 JobQueue::GetJobsInQueue: Ignore 'Flag Commercials' Job for 1002 @ 20051204142500 in Finished state. 2005-12-06 21:22:40.719 JobQueue::GetJobsInQueue: Ignore 'Flag Commercials' Job for 1003 @ 20051204142500 in Finished state. 2005-12-06 21:22:40.719 JobQueue::GetJobsInQueue: Ignore 'Flag Commercials' Job for 1004 @ 20051204142500 in Finished state. 2005-12-06 21:22:40.721 JobQueue::GetJobsInQueue: Ignore 'Flag Commercials' Job for 1005 @ 20051204142500 in Finished state. 2005-12-06 21:22:40.721 JobQueue::GetJobsInQueue: Ignore 'Flag Commercials' Job for 1006 @ 20051204142500 in Finished state. 2005-12-06 21:22:40.721 JobQueue::GetJobsInQueue: Ignore 'Flag Commercials' Job for 1007 @ 20051204142500 in Finished state. 2005-12-06 21:22:40.721 JobQueue::GetJobsInQueue: Ignore 'Flag Commercials' Job for 1002 @ 20051205043000 in Finished state. 2005-12-06 21:22:40.722 JobQueue::GetJobsInQueue: Ignore 'Transcode' Job for 1002 @ 20051205043000 in Errored state. 2005-12-06 21:22:40.722 JobQueue::GetJobsInQueue: Ignore 'Flag Commercials' Job for 1002 @ 20051206172000 in Finished state. 2005-12-06 21:22:40.722 JobQueue::GetJobsInQueue: Ignore 'Transcode' Job for 1002 @ 20051206172000 in Errored state. 2005-12-06 21:22:40.873 adding: sbe as a slave backend server 2005-12-06 21:22:42.713 Reschedule requested for id 0. 2005-12-06 21:22:42.713 Reschedule requested for id -1. 2005-12-06 21:22:42.800 Scheduled 0 items in 0.1 = 0.08 match + 0.00 place 2005-12-06 21:22:42.804 scheduler: Scheduled items 2005-12-06 21:22:42.806 Seem to be woken up by USER ...and here's what happened just after recording commenced, including the start of the recordings and the first 10s update. (And yes, it -does- appear that ch7 was recorded on the SBE's tuner, and ch7 is the one that later got the error transcoding---since I'm pretty sure that cardid 6 is the SBE's 350, since that was the card I defined last when running mythtv-setup.) Note that there was never an entry showing the start or end of transcoding for ch7 (the one that errored). 2005-12-06 21:35:02.944 Started recording 2 WGBH - 21:35 (Manual Record) on channel: 1002 on cardid: 1, sourceid 1 2005-12-06 21:35:02.948 New DB connection, total: 4 2005-12-06 21:35:02.951 New DB connection, total: 5 2005-12-06 21:35:02.971 scheduler: Last message repeated 8 times 2005-12-06 21:35:02.974 scheduler: Schedule Change 2005-12-06 21:35:02.975 Started recording 3 LOOR003 - 21:35 (Manual Record) on channel: 1003 on cardid: 2, sourceid 1 2005-12-06 21:35:02.977 Started recording 4 WBZ - 21:35 (Manual Record) on channel: 1004 on cardid: 3, sourceid 1 2005-12-06 21:35:02.978 Started recording 5 WCVB - 21:35 (Manual Record) on channel: 1005 on cardid: 4, sourceid 1 2005-12-06 21:35:02.979 Started recording 6 WFXT - 21:35 (Manual Record) on channel: 1006 on cardid: 5, sourceid 1 2005-12-06 21:35:02.981 New DB connection, total: 6 2005-12-06 21:35:03.014 New DB connection, total: 7 2005-12-06 21:35:03.016 New DB connection, total: 8 2005-12-06 21:35:03.018 New DB connection, total: 9 2005-12-06 21:35:03.021 New DB connection, total: 10 2005-12-06 21:35:03.022 Started recording 7 WHDH - 21:35 (Manual Record) on channel: 1007 on cardid: 6,
[mythtv-users] Very low audio level after transcoding
In 0.18.1: I'm experimenting with transcoding from MPEG2 to MPEG4, and have discovered that the transcoded files have very low audio levels; I'd guess on the order of 6-9dB down from the source, at least. Where are these levels specified? I'm quite surprised that they're affected at all. I'm using all the defaults (as far as I know) except that I changed the transcoding dimensions from 480x480 to 720x480 to match the original from the PVR-250. I can verify absolutely that it's the transcoding process that's doing this, because I'm saving the originals. If I play the transcoded file, and then rename that file to some temporary name and rename the .nuv.old file in place of the original and play -that-, audio is back at its normal level. If I undo the renaming, audio is again quiet. This is true for transcodings from 5 different channels. According to ps, the actual transcoding process was something like: mythtranscode -V 4099 -c 1002 -s 2005-12-06T21:35:00 -p autodetect -d ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] remote-controlled mythfrontend?
Date: Sat, 03 Dec 2005 02:25:16 -0500 From: Michael T. Dean [EMAIL PROTECTED] You should execute it as the same user running X. Oh duh! I -told- you I was being dumb. :) Thanks. Yeah, doing that (and either inhibiting X forwarding or undoing it) worked just fine. mplayer plays video over the mythfrontend menu. (I may have to diddle around with what -size- it tries to render to, but hopefully that won't be too much of a pain and hopefully the xv inside ivtv can scale fast enough on this AMD 2800+. I'm running ivitv 0.4.1 [not .0 'cause I'm debugging an audio issue right now].) I presume I'll have to loop the 350's audio outputs through my motherboard's soundcard and use the mobo soundcard output as the output to the TV to hear any audio, since mplayer has no idea what a 350 is and hence isn't routing audio to it... :) I'll have to dig up some appropriate connectors to test that, and unclick the appropriate setting in mythfrontend or mythtv-setup [whichever one it is]. Now it'll just take a little bit of scripting magic to do what I want to do with mythweb, but it should be feasible, and I don't have to worry about the frontend at all. Thanks! P.S. Watching video through the 350 -and- playing video on top of it with mplayer leads to bizarre and interesting results, but at least nothing wedges or hangs; it just looks peculiar. Not surprisingly. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] remote-controlled mythfrontend?
Date: Sat, 3 Dec 2005 03:05:05 -0500 (EST) From: [EMAIL PROTECTED] (I may have to diddle around with what -size- it tries to render to, but hopefully that won't be too much of a pain and hopefully the xv inside ivtv can scale fast enough on this AMD 2800+. Yup, -fs does the right thing and runs just fine, and my CPU is essentially unloaded (90% idle). Yay. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] remote-controlled mythfrontend?
Date: Thu, 1 Dec 2005 22:48:24 -0700 From: Chad [EMAIL PROTECTED] You -could- use jump points. You -could- be quite clever :) I'm not sure this will work, but it might get me somewhat closer. I take it your idea is to set a jump point to the Watch Recordings page, and then infer how many clicks down to jump based on what's being displayed in mythweb. Even better, if it can be made dynamic enough, would be to have whatever script is being called via a mouse click on mythweb to (a) notice what show it is, (b) talk to the DB to set a jump point right to that precise point (if jump points are that flexible; I'm having trouble finding good documentation on them without reading the code), and then (c) invoking the jump point. Might work. I'm hoping there's something more direct, or some real protocol support, but it's at least conceivable it could work... ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] remote-controlled mythfrontend?
Date: Fri, 2 Dec 2005 17:35:10 -0500 From: Chris Ribe [EMAIL PROTECTED] Out of curiosity, what is your goal here? [See my next reply (to Kuphal).] If you don't need the myth interface, something along the lines of typing mplayer filename should get the job done. That's a fascinating idea. I'm not sure it'll work, though. I'm displaying the output via the TVout of a PVR-350, and I'm not sure that the frontend isn't holding the card in some weird state that would prevent something else from streaming an mpeg to its decoder, which was why I wanted to do it through the frontend itself. If that doesn't matter, then that makes life easier. But I can't test it, because I have a second problem: I just noticed that I can't seem to get anything X to work remotely on the frontend. I'm ssh'ed in, and of course ssh sets DISPLAY to its own forwarded connection, so I have to change that or everything will just display back on my desktop where I'm typing. If I try export DISPLAY=:0.0 then even trivial things like xterm say ``Xlib: connection to :0.0 refused by server'' and ``Xlib: No protocol specified''; thinking that this is a permissions problem, I tried xhost + and got the same error, so it's clearly having troubles connecting to the server. Replacing :0.0 with localhost:0.0 changes xhost's behavior: now it pauses for a few seconds (trying a reverse lookup that's failing? I dunno) and then claims ``xhost: unable to open display localhost:0.0''. X -is- running on the frontend, of course: The logfile claims it is, and mythfrontend is running, and (before I made the mythtv user start it up automatically), I was presented with the standard X login screen that Ubuntu provides; I can see mythfrontend running from under gdm in my process table. (I see /usr/X11R6/bin/X :0 [etc] in ps, and I did try just :0 and that didn't change anything, either.) On the other hand, if I try ssh'ing from desktop machine A to machine B, doing export DISPLAY=:0.0, and then trying an xterm, without even xhost +, an xterm pops up on B as expected. Yet this doesn't work at all if I try it to the Myth frontend machine. (And they're all running Ubuntu Breezy.) So I'm obviously missing something dumb... ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] remote-controlled mythfrontend?
Date: Fri, 02 Dec 2005 16:40:28 -0600 From: Kevin Kuphal [EMAIL PROTECTED] No, there is no facility in Myth to send playback commands to a frontend to make it play something. The closest are the MythWifi type applications that let you send remote keypresses to the frontend but you still need to get the combination correct. And out of curiosity, why are you using MythWeb on a different computer from your TV to start watching a program on a TV across the room that you are not in front of? Well, I'm -sort of- in front of it. Think of a setup where I've got a real desktop in front of me, and a large TV display in my line of sight at a comfortable viewing distance. I was really impressed with the organizational ability of mythweb to show me a lot of information on the high-res computer screen that's right in front of me, with a good interface (e.g., keyboard mouse), [*] and it'd be nice to take advantage of that seamlessly: if I can delete or otherwise muck around with recordings as shown by mythweb, why not watch them, too? And that way I can use the computer display for what it's intended (dense display of lots of text) without trying to strain my eyes reading a tenth as much text, fuzzily, on the TV. There's another reason lurking here, too---it'd be really nice to be able to jump around in realtime in mythweb's display, effectively queueing up the next thing to show, while the TV is still showing the last thing---basically VJ'ing. This is in pursuit of a media analysis system, though, rather than an entertainment application :) [The real-time nature is important, because there may be discussion amongst the group that would cause the operator to pick a recording out of a library, so they can't just be edited together in advance and queued up as a single recording.] [*] [When it's not confusing me and putting weird stuff in my to-be-recorded queue, anyway; see my bug report of 12/1 21:27:22 about various mythweb manual scheduling bugs in 1.18.1.] ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] remote-controlled mythfrontend?
Date: Fri, 2 Dec 2005 19:37:35 -0500 From: Dewey Smolka [EMAIL PROTECTED] I don't know if this is what you're looking for, but I use Xvnc to control a FE remotely (you'll probably have to install but it's no problem). From your remote machine, ssh into the Myth machine you want to control, launch (mythuser)$Xvnc display:0 (I belileve. Anyway it's in the README), and launch vncviewer on your local machine. There a few things that need configuring, but it's all in the docs. This creates a clone of the current Myth X display on your remote machine. Start your film from the regular Myth menus, close the vnc session, and go watch. I have no idea if this works on MS, or if (On MS? You mean in Windows? Not an issue; all Linux boxes.) that's even an issue for you. Maybe not as elegant as a FF plugin but easy and effective. Hmm. That's interesting; I'll have to go take a look at it. If it's an exact clone (e.g., I see the normal frontend menu, as opposed to what mythweb can do for me), it's not quite as useful, since the idea was to use the high density of information mythweb can give me, but it's still worth investigating... Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] How big is your database?
Date: Thu, 1 Dec 2005 15:17:53 -0800 From: andrew matthews [EMAIL PROTECTED] I use XFS it can be both grown and shrunk. My manpages and google both seem to disagree with you; neither xfs_growfs nor xfs_admin claim to be able to do this. If you've successfully shrunken an XFS filesystem (-not- the underlying partition, but the actual filesystem itself), without having to simply dump it elsewhere and recreate it smaller, I'd be very interested in knowing what command(s) you used and what distribution you're running. Tnx. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] various mythweb manual scheduling bugs in 1.18.1
In mythtv 1.18.1, using mythweb: Trying to schedule a manual recording is... peculiar. I've done some searching but haven't been able to unearth any reports about this, but perhaps I'm just looking in the wrong place. If I click on Manually Schedule, adjust the start time to be a minute or two in the future, adjust the length to 2 minutes, and click Create Schedule, it pops up a slightly different menu that says Save Schedule at the bottom. Nothing has actually been scheduled yet, though, according to the Scheduled Recordings page on my frontend, or in the same page in mythweb. And clicking on Save Schedule is a no-op; I just get the same page back, over and over and over. HOWEVER, if I instead click in the Schedule Override section for Record this specific showing, it then puts me back in what looks like first menu again (fewer options), but with Save Schedule still at the bottom. Clicking Save Schedule still doesn't cause the schedule to be created. If I then -undo- that override by clicking on Schedule normally', THEN the Save Schedule button actually schedules the recording. I just repeated this about 5 times in a row to convince myself that this was what was really happening. Even weirder, if I don't touch the start time or the length, THEN the Save Schedule button pops up the second page (with Create Schedule), BUT it's already been scheduled before I can even edit that page, and so the recording starts instantly---the FE, mythweb, and the tuner status all say a recording is going on. So apparently things are different if the recording starts this instant vs if it starts a few minutes in the future. [-Or- it's the length part, but see below for why I'm giving up on debugging this further right now.] Furthermore, while trying to debug this, I now have a recording in the Scheduled Recordings page in my FE that's -in the past- and yet claims to be recording, and is unkillable---I can't make it go away from that page (even though no tuner is currently recording). It's definitely red (like a recording that's actually recording) even though its start and end time are several minutes in the past. I haven't tried all the other possibilities in the mythweb UI because I'd like to at least figure out how to undo whatever it did just now, and to find out if this behavior might be fixed in SVN or if it's just rare that people schedule manual recordings. (Or if there's some bug having to do with specifying its length or start-time.) How is this menu -supposed- to work? [And should I just avoid manual scheduling in mythweb in 1.18.1?] Thanks... P.S. Delete in the Scheduled Recordings page in mythweb didn't do at all what I expected---it set an override saying don't record this manual recording instead of just deleting it outright, as the similar command in the FE would do. If I schedule something and change my mind, how do I get mythweb to just -forget- about it and not mark it as a scheduled recording that's been overridden not to happen? Are mythfrontend and mythweb supposed to be incompatible in this way? P.P.S. Rebooting the backend made the phantom recording at 20:47 finally vanish. However, it -then- instantly started recording another manual recording, claimed to start at 20:44, and which was -not- in the display before I rebooted. Using Stop Recording in mythfrontend actually got it to stop, and its color has now changed from red to gray and it's marked S there (and the tuner is marked not recording). [It's still hanging around, gray, in my Scheduled Recordings menu in the FE, though, even though it's now been about 15 minutes since the recording stopped; apparently that's because it was one of the default-2-hour recordings from mythweb, because it claims to have recorded from 21:03 to 22:44 (even though it's only 21:18 here at the moment; I'm guessing that I stopped it at 22:44, but those times still don't make lots of sense to me). I'm hoping it will finally vanish from the Scheduled Recordings page on the FE sometime after 22:44. It's -really- confusing---the actual one-liner at the top of my FE's screen says 21:03, then the channel ID, then Thu Dec 1 20:44:00, but the details display in the bottom half of the screen claims 21:03 - 22:44 (there's -no way- I set those times myself, and they don't correspond well to when I booted/cancelled anything), even though the line right underneath -that- also claims 20:44:00 just like the highlighted line at the top. WTF?] ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] remote-controlled mythfrontend?
While I'm poking at mythweb... If I'm surveying my already-recorded programs, and click on one of the thumbnails, mythweb currently tries to send the .nuv (really mpeg) file directly to my browser, which is running on my desktop machine [not a Myth box]. Firefox has no idea what to -do- with the file, so it tries to inhale hundreds of megabytes and explodes. Presumably the solution there is to figure out what MIME-type mythweb is using to represent these files and define a mapping to something else, like mplayer, but I haven't looked at that yet [is it documented somewhere?].) But in fact, what I -really- want to have happen is to be able to tell my frontend, which is across the room and has the PVR-350 which is the actual TV output, to go play the thing I just clicked on. Has anyone ever implemented this sort of functionality? If not, I can deal with writing some sort of glue script that gets called by Firefox (and which -hopefully- also gets the relevant filename), but it'd be great if someone already has the relevant code snipper to get mythfrontend to do the right thing once I know what's been clicked on. (Otherwise, I guess, I need to figure out how mythfrontend arranges to get something played, and try to do so by hand, and figure out whether that's going to fatally confuse the mythfrontend that's running as to what's going on at the moment.) Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] remote-controlled mythfrontend?
Date: Thu, 1 Dec 2005 23:09:02 -0500 From: Chris Ribe [EMAIL PROTECTED] MythWiFi is what you are looking for. Search for it. Huh. I'd -never- have guessed from the name; I assumed that was some sort of bandwidth-scrunching thing for people who wanted to stream video over 802.11. Thanks! ...though from its website documentation and a quick look at its code, it -looks- like it basically sends fake keypress events to the frontend, acting essentially like an IR remote control, e.g., to do anything, you have to be looking at the frontend and know what state it's in, etc. Do you know offhand if anyone's successfully used this more for play this specific thing rather than for emulate these buttons? I -suppose- I could either (a) script it so it backs all the way out to the top of the UI no matter where it might be starting from, then goes back in and pages down to the right thing and plays it, or (b) use the general idea and have it talk more directly to the DB and frontend (but if I'm not simulating buttons, I'll have to make sure I'm not confusing the front end...). ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] SBE tuner unavailable after MBE reboot?
Date: Wed, 30 Nov 2005 01:15:05 -0800 From: Cecil Watson [EMAIL PROTECTED] All you need to do is restart the backend on the SBE... Sure. But I'm surprised that the two ends of the connection can't recover on their own. (They -almost- do, since the UI recovers, albeit ungracefully, but the tuner is left unavailable.) Is the protocol supposed to handle this case? If so, this is a bug; if not, I'd like to request the obvious feature... :) [Or figure out how the SBE can tell that the MBE thinks the SBE's tuner is unavailable, and have the SBE restart its own backend. But that seems like quite the kluge.] ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] How big is your database?
I'm about to repartition, leaving everything except recordings in an ext3fs partition, and putting all recordings into JFS. But I'd rather not discover that I've made the ext3 too small, and I'd rather not waste gigs making it too big. The only thing I have no idea about is whether the mysql database tends to grow monotonically or not, and how large it typically gets. Can somebody give me an idea of how large a database typically is after Myth has been used a long while, or how fast it grows? I'm guessing that deleting a recording will correctly flush everything else associated with it (cutlist, mythcomflagging, etc), but does the DB keep any records of -everything- I've ever recorded, and will those be likely to expand to large proportions? (Basically, does the DB bloat/leak as time goes on...) And if I do mysqldump, is that likely to be enormous? (I'm guessing that it won't be if I pipe the result through gzip before putting it anywhere, but I don't have a big-enough DB yet to really know.) (If the answer is, up for years and under a gig, I won't worry about it; I need at least a gig or two of slopspace just to make upgrades easier, etc. But if the answer is a gig a year or whatever, I'll worry. I'm having a hard time discovering this via websearching.) My other alternative is to put the DB in the JFS, but I'd rather keep it separate so I can relatively easily nuke that partition without worrying about the DB---especially since XFS/JFS are clumsy to resize (especially to shrink). Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] How big is your database?
Perfect; that's fairly slow growth. Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Uncool surprise... coming back from vacation, shows not recorded.
I've been thinking about this issue quite a bit recently. I have half of a solution but need a little bit of advice on how to make it a whole solution; if even one person has an idea about how to address each of 3-4 problem areas, I can put together the pieces and post it back for everyone to use. (All of these presume you're starting with an mpeg.) What I'm trying to do: Have Myth notice that a recording is bad and autoreschedule a new one. (If there's no repeat, well, you're SOL, but often there is---if only you knew about it soon enough!) This could be extended to and send mail screaming bloody murder to warn people of misconfigurations/dead-machines whatever as well, of course. In my experience, three problems happen: o No video. For example, one of the local PBS affiliates -frequently- airs totally black video in place of a show. (This probably happens once a month, usually in the dead of night when nobody at the station is awake.) They'll air the promo, then cut to black, and then at the end of the hour, the next promo... So there's sync, the card's working, etc, but there's no -content-. o Crappy, unwatchable video (half-destroyed by static, etc). This is typically because the studio feed crapped out somehow. I've sometimes seen shows slowly degrade from fine to total snow over the course of half an hour. Discovery Channel seems particularly prone to this sort of failure, at least here. o No audio. I've seen this in ivtv (working w/Hans to track it down in my case), and sometimes the station blows it, too. Partial ideas for solutions. Help appreciated! o Either look for a suspiciously-small output file (will all that black video produce a very small mpg? Or will it be close-enough to normal size that a heuristic like this won't work?), or have something that counts scene changes and complains if the average is too low. I'm guessing that the guts of mythcommflag might have some of the relevant code, but is there some easy way running something (mencode, or some other tool that groks mpegs) and just having it output the number of scene changes, or something like that? Surely somebody has this tool already. o I dunno how to notice high static. Does it tend to interfere with scene-change detection? Can it be guessed by running some sort of Gaussian filter over a few frames and seeing if they clean up too much or too little? Excessive high-frequency information in either the chroma or luminance channels? The image-processing community probably knows how to do this, but maybe there's a quick easy idea someone has here, given that we're already talking about mpegs. o Dump the audio out (mplayer input -dumpaudio -dumpfile output) and then look for excessively-low average, or sample it for a few seconds every few minutes and complain if too many of them are silent (or close to silent; compensates for hum, etc). There's probably some simple audio tool that can do this, but I don't know what off the top of my head. The final problem: instructing the backend to retry the recording. This is presumably some simple SQL magic. But what? Thanks for any ideas anyone can suggest... P.S. Is there an easy tool of producing a series of thumbnails of every scene change from a section of video? (Or perhaps just a single frame from every n minutes, regardless of scenes.) That would be handy no matter what, to quickly notice that the middle of something got trashed, or to make it possible to notice that, e.g., PBS decided to show an hour of Exciting Legislators Voting and Debating instead of whatever they originally scheduled, which also happens quite a bit here... :) The idea is to have something so low-bandwidth that it could be quickly checked at the other end of some network link far from home, allowing manual rescheduling via mythweb... ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] How big is your database?
Date: Thu, 01 Dec 2005 12:54:44 +0800 From: W.Kenworthy [EMAIL PROTECTED] Use LVM. Yes, I know about LVM, but it doesn't solve my problem, because the -filesystems- can't be easily resized. (ext3 is easy; it can grow and shrink. One of JFS or XFS [I can't recall which] can only be grown. Neither can be shrunk. So if I might have to copy the entire filesystem -anyway-, LVM does me no good unless I need to expand to other disks, and I'm not going to be using the recordings directory in that way. And while I use LVM on some of my hosts, it's not compelling enough to use it in the Myth, since it's -much- more of a hassle to swap disks around or do dd-style temporary mirroring (e.g., for experimentation or to save a disk before it dies) with LVM. On my regular workstation hosts, sure, LVM is exactly what I want, so I never have to worry about which disk has space for this tree? sorts of issues. But they all run a single ext3fs, which is easily resizeable, and that resizeability is why I initially didn't want to use anything else for Myth. But its poor deletion performance means I should change. [I could redo the entire FS without largefile4 support and win a bit, but it's not a great solution and actually -more- work than repartitioning.]) And I won't use reiserfs. Not 3, not 4. Never again. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] 1 tuner, overlap consecutive recordings on single channel
Date: Tue, 29 Nov 2005 18:01:40 -0500 From: Michael T. Dean [EMAIL PROTECTED] Nope. It's never worked the way you're theorizing. There's something more going on that you didn't notice. Are you sure the Good Eats episodes were back to back? It would, however, be seriously cool if Myth could cope with this, and I have an algorithm below for how. [One of my major annoyances with a single-tuner TiVo was trying to simultaneously deal with imprecise start/stop station timings versus back-to-back episodes; in general, if you don't want to lose the start or end of something (and hence add pre/post-roll), a TiVo will miss every other episode in a marathon, and so will a Myth. And if you eliminate the pre/post-rolls, you're still not guaranteed not to have the first or last few seconds of an episode wind up in the wrong actual file, -and- you'll lose a few seconds no matter what as it (unnecessarily!) reinitializes the tuner. The workaround there required noticing the pattern before recording, and then manually recording a giant block that spanned the entire time interval (and had pre/post rolls at the ends). This means you lose the per-episode information -and- can't delete a single one, since it's one giant block.] But Myth -could- do better that this---though it might require taking too large a pair of pliers to its inner architecture (I don't know enough to be sure). My proposed solution would be: (a) Notice whenever a pair of recordings has a nonnegative temporal overlap (e.g., they butt up against each other, or they actually overlap each other---this overlap could be because of pre/post rolls, or because of manual programming of start/stop times). Whenever this happens, ensure that both recordings are forced to the same tuner, and -do not reinitialize it- at any time during the overlap. You want this to be true even during a butt and not just an overlap, because you can lose many seconds while the tuner gets told to retune even the same channel (tuner lock, OSDs from some cable boxes, etc). [Does Myth already have this do-not-retune optimization? I'm wondering what happens if you have 2+ tuners fed from one cable box that requires an IR blaster; many boxes will display the channel number and/or pop up an OSD as it's typed and that would ruin any recording still in progress, even if the two tuners would otherwise handle the situation by each encoding during the overlap interval. I don't have that sort of HW setup (yet) so I can't test it.] (b) During the overlap interval, copy data from the tuner to two different files instead of just one (e.g., the files for the first and second recordings). Yes, this doubles I/O to the disk for a few minutes, but disk I/O bandwidth is plentiful. (And obviously, if we're doing software encoding, that happens upstream of this so it's only done once; all I'm talking about here is putting the bits in two places, possibly with any required header when the second file gets opened, and/or starting on the correct frame/ format boundary, etc---but all this code must already exist.) (c) Iterate: consider each pair of recordings on the same channel until you come to a gap. (This might just happen automatically without any explicit iteration, depending on how (a) is done.) This will consolidate any number of same-channel recordings. This -seems- easy enough, but the devil is in the details: getting the overlap detection integrated probably has some picky corner cases, and I don't know if the internal architecture is flexible enough to dump a stream to two files simultaneously. But they seem doable. And this would make a reasonably common situation require -half- as many tuners as it otherwise would, while leading to superior results. (This really comes out if you're unlucky enough to want to record -two- channels, each with back-to-back stuff; now you'd suddenly need -four- tuners without this optimization.) So it might be that a few dozen lines of code could save a bunch of hardware. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] SBE tuner unavailable after MBE reboot?
I've got a two-machine MBE/SBE setup running 1.18.1. (The SBE is also being used as my FE; the SBE's NFS-mounts its video-storage dir on the MBE and hence stores its video there.) I've noticed that if I have to reboot the MBE, then even after it's come back up, and even after mysqladmin ping from the SBE claims the MBE's DB is available (and even several minutes afterwards), the very first time I try to do anything in the mythfrontend (still) running on the SBE/FE, it claims that it can't talk to the backend DB---but as soon as I click OK on that alert, it can clearly talk to the MBE. More annoying, though, is that the tuner on the SBE is then listed as not available if I go to the System Status page, and I presume this means that no captures will happen using it. I have to reboot the SBE to fix this; presumably what's really going on is that I need to restart the mythbackend running there (but I haven't tried doing just that). Is this intended behavior? (I can't see why, if so.) Is it already fixed in SVN? Is there a sensible way to work around it under 1.18.1? (Otherwise, I have to have my SBE monitor the MBE for crashes and restart itself if it sees one; while the MBE can't be expected to crash on a regular basis, I'm trying to get a robust solution in the face of a power fail and restart, and it's looking like I'm going to have to keep the SBE from even starting mythbackend until the MBE's DB is available if they both power up at the same time. Otherwise, the SBE comes up with its tuner in this unavailable state and might stay that way a long time. And it's certainly irritating right now while I'm frequently reconfiguring my new MBE installation.) Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Stop / Start Athcool just Befor / After a Recording
Date: Wed, 23 Nov 2005 12:33:22 -0500 From: Erik Karlin [EMAIL PROTECTED] you could just hijack the channel change script functionality and create a user job when the recording completes. The problem of back-to-back recordings is still possible. maybe some clever file locking scheme between a channel change (start) and user job (end) could do the trick. [There's nothing out there that looks at CPU utilization and leaves low-power mode if the CPU suddenly looks busy? Or is the problem latency? Laptops do this kind of CPU cycling all the time... Or is it that the CPU never looks busy, but recordings are messed up even so, if done in powersave mode?] Here's a totally gross idea, but it might work, and could be done with a tiny shell script. Assume we start from the powersave state. The script loops, once per second, checking the mod-date of the recordings directory itself. If it changes, immediately go to non-powersave state. Once in that state, check every so often (once a minute?) to see if any file in the recordings dir has been modified. (You can't just check the mod-date of the dir itself, as in the previous paragraph, because once the file has been created, the mod-date of the dir itself won't change.) If nothing's been modified in the last minute, assume we're done for the moment and go back into powersaving. This check is probably cheap (since the dir info is presumably cached in RAM), but it still may not be as cheap as checking just the dir-mod date itself, which is why I mention using the dir-mod check in the fast loop (1 Hz) and the slightly-slower check in the slow loop (1/60 Hz). You could script this pretty trivially just using things like find and asking it to find files newer than a reference file (which you touch upon entering each of the two states and which had better not be in the recordings dir itself... :) This also assumes you can afford to be in powersave mode for the first second of any given recording. [If you can't, you could always just enter fast mode for hh:mm:59..hh:mm+1:01 (two seconds) every minute--- since recordings presumably always start on a minute boundary---and then run the fall-back-to-powersave check during that. Might cause your fan to whoosh in one-minute cycles, though...] This scheme does, at least, provide some hysteresis, so you won't leave the fast-CPU state until you're really sure you're done recording. And if anything else is modifying stuff there (like transcoding maybe?), you'll stay in fast-mode until it's done. It would definitely be better if there were hooks for MythTV actions, though, since using an event-driven style to control this would be much more reliable and less of a kluge than the polling method above. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Yet another ugly bit of usability surfaces
...nd, back to my least-favorite form: Capture Cards. Here I am, sitting in Capture Cards in my misconfigured R5A22: Capture cards (New capture card) [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] There are actually only 4 tuners in the machine right now, 'cause I stuck a video card back into it. Booting it caused it to prompt for the root password and then run mythtv-setup automatically, presumably because a tuner vanished, although it didn't have the decency to say so. Why there are -still- five tuners in the list above is... dubious. This leads to a really interesting question: if I boot it headless, 'cause I've added a tuner, does that mean it tries to run mythtv-setup on its nonexistent X display? Or does it just err out? I sorta hope the latter, so there aren't two copies running (the other being on my ssh connection) while I'm trying to reconfigure the device numbers. I'm afraid to try to fix this by running mythtv-setup on the -frontend-, of course, which is the machine with a single 350 in it, since it's my understanding that mythtv-setup will wind up setting up only the cards in the machine it's run on, though talking to the database wherever that is. So really, I have to ssh in. Right? At least once I replace the video card with the fifth tuner. But wait, it gets much better. I go down to the SECOND tuner in the list, e.g., Capture cards (New capture card) [ MPEG : /dev/video0 ] -- [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] I hit Return. I go to Video device and carefully use the arrow keys to change it to /dev/video1, knowing as I do (now) that typing in that field will be thrown away as soon as I select the Finish button. I hit Return. -Now- the menu looks like this: Capture cards (New capture card) [ MPEG : /dev/video1 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] WTF??? This is absolutely repeatable. I just did it three times in a row, to prove to myself that I hadn't screwed up and picked off the wrong entry without noticing. So apparently the position of the tuners in the list is random? Meaningless? Is there any way to keep track of the tuners? Does their order matter? Is whatever is called /dev/video0 used -first-, assuming I haven't gone into the priorities menu and changed that? Or is it the top tuner in the list? Or is it something else? This matters for a number of reasons having to do with (a) debuggability, (b) the principle of least surprise, (c) cabling, and (d) sources. Or, I suppose, I could (and probably should) just flush all my tuners from the database and start over. And probably boot. And powercycle. And leave the machine off for a minute or two first. Where's that chicken I'm supposed to be waving? Dead of avian flu? Well, it was supposed to be dead anyway... Especially since, if I -now- pick off the second in the list: Capture cards (New capture card) [ MPEG : /dev/video1 ] -- [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] ...I can change it to /dev/video2 and its order doesn't move around: Capture cards (New capture card) [ MPEG : /dev/video1 ] [ MPEG : /dev/video2 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] [ MPEG : /dev/video0 ] ...and if I continue to do that (e.g., pick off the third in the list, then the fourth), I eventually wind up in this situation: Capture cards (New capture card) [ MPEG : /dev/video1 ] [ MPEG : /dev/video2 ] [ MPEG : /dev/video3 ] [ MPEG : /dev/video4 ] [ MPEG : /dev/video0 ] ...and now there's this interesting thing: Because there's no fifth tuner in the machine, the /dev/video4 entry WON'T LET ME CHANGE THE DEFAULT INPUT from Composite 0, though it won't tell me why---the field just magically won't accept a new setting from the arrow keys. At least, I -assume- the lack of a fifth tuner, when it was originally configured to have one, is why this behavior is happening; I can only guess. So why's the entry there? How come I could change its device number, but not its default input? If I can't actually -do- anything to the damned thing, and in fact the tuner isn't even in the machine, why am I presented with the tuner? And if the idea is to enable me to change it and -then- stick in the tuner, why is it preventing me from changing the default input? This whole menu needs a complete re-think. Yucko. P.S. If I change an entry from /dev/video0 to /dev/video1, the input magically changes from Tuner 0 to Composite 0. That's pretty annoying; now I have to change it back. And then I'm left wondering, is there some sort of leftover Tuner 0 on /dev/video0? I don't even know if that's a well-formed question; probably not. It
[mythtv-users] MythTV Installer Usability: An Analysis
Date: Fri, 04 Nov 2005 18:32:51 +1000 From: ffrr [EMAIL PROTECTED] Is this because the ringbuffer file seems to continually grow? I have noticed this. Why does it do that? If you are not paused, surely the file size should remain stable? Yes. The ringbuffer grows monotonically -up to its configured limit- and then (I assume!) stops growing. It's not clear to me why the installer defaults to a partition sufficient to hold 5.3 hours' worth for a 200GB disk, though; that seems like an awfully large buffer. (I've cursed my TiVo's half-hour buffer, but it's seemed to me like a couple of hours should be plenty. Maybe it's 'cause Myth doesn't allow you to dump the ringbuffer into an active recording [e.g., you see something on TV you didn't know would be on, and decide you want to save the entire thing, including what's already been aired], and without this capability you tend to need a much larger ringbuffer? I dunno. I -do- hope that this capability is added someday; it's been a real lifesaver on my TiVo.) The problem is that the eventual upper bound of the ringbuffer, at least with the sizes I got by default (and, apparently some others in the KnoppMyth forum) is a couple GB -larger- than the size of the partition the installer allocated for it, and Myth handles this... ...poorly. To say the least. Obviously, the two halves of the installer need to talk to each other, to the pick the right sizes, or at least the ringbuffer-defining half needs to actually look at the damned partition and make the intelligent guess that (a) its default should not be bigger, and (b) the user should not be allowed to -make- it any bigger, either. In the current case, the installer defaults to behavior that will cause the machine to livelock and explode if the user has the bad luck to leave the UI on the wrong screen and go to bed. Whoops. P.S. The current installer's default of such a large ringbuffer and ext2 (ext3?) also has the problem that trying to switch away from live TV back into the UI can take a -very- long time---apparently the ringbuffer is deleted immediately (hey! but what if I wanted to finish watching something after doing something in the UI! now it's -gone-!), but deleting 12GB in that filesystem takes something like a second per GB, at least, even on fast hardware, because of all the disk thrashing that's required. The first time this happened to me (while testing the above behavior), I was wondering if the machine was -again- wedged, until the UI finally reappeared. Other filesystems (XFS? JFS? I don't remember) are apparently much faster to delete, although using those for the ringbuffer now means the kernel installer need to know about more filesystems have tools to manipulate them, etc etc, more complexity, yadda yadda... Easy enough for a custom install; questionable (maybe) for something like KnoppMyth. I'd be happy to be proven wrong. (And, y'know, I've deleted very large files on identical hardware and didn't seem to wait so long. Either the uncertainty was making it feel like forever, or Myth is doing something -else- weird while that's going on which is making the whole process take even longer. Maybe I'll set up another test someday, but not tonight.) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] MythTV Installer Usability: An Analysis
Date: Fri, 04 Nov 2005 18:32:51 +1000 From: ffrr [EMAIL PROTECTED] Is this because the ringbuffer file seems to continually grow? I have noticed this. Why does it do that? If you are not paused, surely the file size should remain stable? Yes. The ringbuffer grows monotonically -up to its configured limit- and then (I assume!) stops growing. It's not clear to me why the installer defaults to a partition sufficient to hold 5.3 hours' worth for a 200GB disk, though; that seems like an awfully large buffer. Hmm. It belatedly occurs to me, of course, that the installer has no way of knowing at the time it's partitioning the disk whether you're planning on putting an HD card into the machine, either now or sometime in the distant future, and an HD card might require quite a bit of disk space to have even a moderate-duration buffer. (This also makes the time-to-explode far shorter in this case.) What -really- doesn't make sense to me, though, is why this thing is in its own partition to start with. Why not just put it in the same partition that holds recordings? Then it could trivially be as large as the freespace on the disk, while not actually soaking up space used for recordings if you'd rather use the space that way (e.g., just dynamically adjust the ringbuffer to never exceed the freespace on the device, plus maybe a margin so it can shrink over time if the rest of the partition is filling up with recordings from other tuners). The current situation just wastes a lot of disk space in order to be less flexible and more buggy. (Is this specific to KnoppMyth? Having not (yet) rolled my own installation from a different distro, it's difficult for me to tell.) This is especially acute if one is setting up an MBE/SBE system, as I am. It's not clear to me at all how many ringbuffer partitions there need to be---one for -each- machine in which some capture card might be looking at live TV? It's tempting to make only one, and share it via NFS, but maybe I can live with one per machine just to make the configuration easier and more robust. I've also seen the installer pick both 12GB and 5GB sizes for that buffer, and I have no idea under what circumstances it decides; after so many reinstalls in the past week, my memory on this is a bit hazy. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Simultaneous recordings fail spectacularly [SOLVED!]
Date: Fri, 4 Nov 2005 10:27:36 -0600 From: Josh Burks [EMAIL PROTECTED] Then why aren't you the one fixing these problems. For as much effort that you put into your posts to this list, you could have rewritten all the code/bugs you're constantly complaining about. Are you kidding me? You're saying I could have fixed every one of these bugs, including (a) discussion about whether it's really the right thing to do, (b) design, (c) coding, (d) documentation, (e) testing, (f) packaging, in less than then ~4 hours it's taken me so far to point them out? Wow, you're -way- more productive than any programmer -I've- ever met... In case you haven't noticed, the unoffical motto seems to be by developers, for developers. Myth's motto is by developers, for developers? Really? Does that motto also mean, We won't lift a finger to make things easier for anybody? On the other hand, if your argument is that MythTV is -supposed- to be annoying and (often) a PITA to install, then that would explain the numerous usability issues I've discovered---they're features, not bugs. I'd be really surprised if you got widespread agreement on that, but if you do, I guess I'll go elsewhere---I deal with enough software that's an unintentional PITA that I have no desire to deal with some where it's a design goal. Or perhaps your argument is, Real developers write code. They do not try to make their users' lives easier, so they do not do usability testing, nor do they point out where that testing shows problems. All that stuff is for wussies. That's a really common attitude among geeks. It would also go fairly far towards explaining some of these apparently-longstanding usability issues. If you don't like something (and it bothers you so bad that it requires a 9391 char post to describe it), then fix it yourself. The code is available, everything you need to know is on svn.mythtv.org, and in the documentation on mythtv.org. There's a reason why I will not, and for that matter -should not-, at least for a while. Why? Because I am brand-spanking-new to the codebase, that's why. If you want people who've never read the code to just dive in with no oversight---and give them privs to commit to the repository---then you're not going to get a very high-quality project. I'm sure as hell not going to claim that I'm going to be able to fix these bugs with good quality from a standing start. And that assumes that those who -do- have commit privs even agree that they're bugs and need fixing. A prerequisite for -that- is making the case for their existence, which is what I'm doing. The first step is to figure out where the bugs lie (Myth? Knoppix? KnoppMyth? ivtv? elsewhere?) and then see if any of them are (a) fixed already, (b) will never be fixed, by fiat of their maintainers, (c) have a possibility of being fixed by someone who already knows the code well, or (d) must be fixed by an outside party. Once we get to (d), that's where I might be able to help. Meanwhile, getting these usability bugs -out there- for consideration is the most effective thing I can do at the moment---especially while they're fresh in my mind, and -before- I'm so close to the problem that I don't consider them bugs any more because I'm too familiar with all the problems. So for the moment, I'll limit my help to gadfly, e.g., what would a reasonably intelligent but FIRST TIME USER think about the usability of the product? Installing Myth shouldn't be a fraternity hazing. One of the problems with -some- F/OSS software is that making it difficult makes those who've managed to struggle through it feel good about themselves, and gives them cognitive dissonance about making it easier for others (hey, why -they- have it so easy when I had to struggle?). One of the reasons for the spectacular uptake of both Mac OSX and Ubuntu, especially among the geek set, is because both projects made a conscious decision to remove as many unnecessary tripwires and inconveniences as possible. Some people have real work to do, and resent wasting their time on rough edges that, with just a little bit of work, could have been removed in the first place. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] MythTV Installer Usability: An Analysis
Date: Fri, 4 Nov 2005 09:55:53 -0500 From: Dewey Smolka [EMAIL PROTECTED] Also you're going a bit scattershot with issues that are specific to MythTV, specific to Knoppmyth, specific to Knoppix-Debian, and specific to your hardware without really thinking about them in context. Yeah, I know, and I apologized for that in advance. OTOH, I've been a little surprised that, e.g., Cecil has claimed as his bugs (e.g., in KnoppMyth) certain things that I would have sworn were upstream in either Knoppix or Myth, so I'm not sure what to think. I'm hoping that the relevant maintainers will at least consider the pieces relevant to their projects. (Though if some of these are upstream Knoppix issues, those people probably haven't even seen any of this discussion. OTOH, those are probably the irritating-but-nonfatal variety anyway, like the annoying timezone stuff.) This still ignores the point that you're not using your appliance in the recommended fashion. You could also complain that leaving your coffee machine on overnight causes the caraffe to become uncleanable and ruined. It may be true, but that is not how you're supposed to use it. It's rarely productive---though an entertaining spectacle---to have an analogy war, but I'll dive in anyway even though I know it's probably a bad idea: I'd argue that a more-correct analogy is, We know how to design this coffee maker so that it will turn off when the carafe is empty, and it wouldn't cost any more to produce nor make the device less desireable from the user's perspective, but we won't bother to implement it, because you're not supposed to be leaving it unattended in the first place---even by accident---and so it's your own damned fault. Let's please not punish the users. Please? This is also likely to be an easy, quick fix, so why are we spending this much effort arguing about it? Sure, there are several independent things to be changed (fix the installer not to guess wrong; fix the UI not to allow bad choices; fix the actual live-tv recorder not to overfill the disk), but each one seems easy, and the end result is a much more robust system. [Btw, I appreciate your later comments on how much live TV differs from actual recording; that's totally nonobvious to someone who hasn't looked at the code, and very much not what I would have suspected, since it's not the design decision -I- would have made... I was thinking last night that one way around the slow delete issues would be to divvy up the recordings into, say, 100MB chunks, and then delete them -in the background- when necessary. But that's probably moot if message about ticket #340 means that live TV will be totally redone anyway.] snip (S-2) The SQL database is being mis-initialized, or whatever is using it is becoming confused, in a way which is causing brand new installations to fail, in the case where the backend and the frontend are different machines. The failure typically manifests as follows: snip Never seen this, but then again, I like to make sure that my BEs are properly set up and network addresses properly set before adding FEs. The steps are fairly well documented. The BE -was- set up first. It has to be, after all. And all network addresses were correctly set. The problem came in -then- setting up a FE that could talk to the BE. THIS IS A BUG---and a new one, apparently. If this is the case, then this is something specific to Knoppmyth, not MythTV. I really have no idea; I'll defer to those who understand the codebase better than I. I'll point out that one of the contributors to the thread made the (uncited) assertion that recent builds of mythfrontend had the bug, and it's my guess that a mythfrontend bug is in Myth and not Knoppix, but really, I don't know. I'd be happy to contribute info on the symptoms, workaround, etc etc, if it would help to fix the bug; all I need is someone who says they're willing to be responsible for fixing it. You may have also noted that R5A22 is based on an SVN build, and as such is not only Alpha (the A), but outside of the stable .18.1 MythTV release. Please see Isaac's comments on this. Yeah, I saw those comments yesterday, and man, I'm sure not happy about the situation. It's one of the reasons I'm considering rebuilding my Myth based on Ubuntu Breezy, right now, even though the setup is -really- already needed for the projects here it's slated for, just so I'm not in a weird and untenable later situation wrt protocol versions and other incompatibilities. (I'd rather trade some additional delay now for fewer surprises later when more people are depending on it.) Either way, this isn't really the place to complain about issues specific to Knoppmyth, since not everyone here uses
[mythtv-users] Re: MythTV Installer Usability: An Analysis
Date: Fri, 4 Nov 2005 13:15:07 -0500 From: Isaac Richards [EMAIL PROTECTED] On Friday 04 November 2005 01:09 pm, R. Geoffrey Newbury wrote: On Fri, 4 Nov 2005 00:33:41 -0500 (EST), [EMAIL PROTECTED] wrote: Date: Fri, 04 Nov 2005 04:36:58 GMT From: [EMAIL PROTECTED] :? Dude, you've describe nothing about MyhtTV Installer in this : thread. Issues w/ KnoppMyth should be posted KnoppMyth forum and NOT on the MythTV mailing list. Lets see: using Fedora Core 4, the various issues of: badly-done mythtv-setup forms (and poor error checking); Argueable. And I'm arguin'! :) In particular, even if you believe that the cursor navigation is perfectly fine, the lack of error-checking in Capture Cards is, uh, disgraceful. Really. I've had several people write to me off-list to say that it's zapped them, too. (I'm trying to get them to repeat this -on-list, if possible.) incorrect initial SQL database population for two-machine setups; knoppmyth bug, since they chose to use a random svn checkout. ...ah. So was this a mythfrontend (or mythtv-setup) bug that was fixed in a later svn version, or did KP break it somehow? It's still unclear to me if anyone can actually point to the line of code involved and say, It's fixed. (Not that I'm arguing that grabbing a random svn was the right thing to do, mind you.) invisible text cursors in network address boxes, Likely due to whatever Qt theme is the default one in knoppmyth. Actually, this might be while the Knoppix installer is running (pre-KnoppMyth, pre-Myth), since it's while configuring the network, so the complaint -might- be w/the Knoppix folks---assuming there's nothing that KnoppMyth can do to fix it on their own (and assuming that wouldn't introduce a fork/tracking issue they don't want). and the installer's ambiguous wording in remote choices; mythtv-setup doesn't have do anything with the remote. Well, it's LIRC's setup script, I assume. (Or was this script custom-written for KnoppMyth? It's hard to tell 'cause KP doesn't publish its techniques source manifest well... everything.) It's whatever script it is that produces a list of about a hundred different remotes, numbered, and says pick one. What is that and who maintains it? are ALL mythtv-setup problems. I've never tried Knoppmyht so I'm not suffering from repressed memories So, no. Isaac ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] manual scheduling - no upcoming recordings
Well, this is new different. So after my little debacle with Capture Cards, and discovering (for example) that there's no way to DELETE a single card from the list without nuking ALL of them and starting over (geez, what happens if somebody moves a card to a different machine? guess they just deserve to lose), I ran mythtv-setup, told it to delete my capture cards, and set up the 4 in the machine on unique /dev/videoN settings. Then, after powering off the machine for a while and back on: (a) It still complains on boot about /dev/video4 not existing. (There used to be a 5th card. Not at the moment.) Who's caching this info? I could post the logs if anyone wants. (b) I went into Schedule Recordings - Manual Schedule and wasted my time setting up 4 simultaneous recordings 5 minutes into the future, only to discover in Upcoming Recordings that it's claiming You haven't yet scheduled any recordings. WTF??? (c) I can repeat (b) at will. Manual Schedule isn't actually doing anything any more. So something just broke in this KnoppMyth R5A22. I can't prove it was related to flushing my capture cards and starting over, but I sure have my suspicions. Has anyone seen this sort of behavior before? ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] manual scheduling - no upcoming recordings
Date: Fri, 4 Nov 2005 17:07:41 -0400 From: Greg Estabrooks [EMAIL PROTECTED] (for example) that there's no way to DELETE a single card from I'm pretty sure that you can just Highlight the card and hit Menu (M). Then pick delete. Such a pity, then that the UI gave me NO CLUE WHATSOEVER that it was possible to type letters when sitting on entries, or what those letters might do. Are there other commands besides M? Where are they documented? Why are they not documented RIGHT ON THAT VERY SCREEN? I mean, there's plenty o' real estate just sitting there blank... Are there other places where typing letters would work? Where? [Typing a ? while sitting on an entry did nothing. Surely I'm not expected to just type every possible character, with and without every possible modifier, to figure out if there are any other easter eggs in this particular screen. And then there are all the -other- screens...] *sigh* . o O ( Usability? ) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] manual scheduling - no upcoming recordings
Date: Fri, 4 Nov 2005 17:01:42 -0500 From: Isaac Richards [EMAIL PROTECTED] I will repeat: You, sir, are way, WAY too close to the problem. You have no conception of what it's like to be a first-time user. Therefore, your opinions on what's obvious or easy are not to be trusted. Have you ever used _anything_ with a remote control before? I guarantee that there's not a Press the 'Guide' button to bring up the program guide message burned in to your TV from it being displayed all the time. I'm not -using- a remote control right now; I'm using a keyboard, because I'm trying to get the box set up. Because mythtv-setup is often used when (surprise!) setting up the box, you can't assume that everyone's using a remote. They might not even have installed LIRC yet. Burying functionality is a bad idea. Did you even bother to read the mythtv howto? It lists all the commands: http://www.mythtv.org/docs/mythtv-HOWTO-11.html Of course. Did I commit every turn of phrase to memory? No. The whole -point- of big pretty UI's is to -avoid- forcing users to read manuals. And let's face it, Myth requires plenty of reading of random manpages, web pages, and everything else already. The less we must force people to crawl through the doc to find buried features, the better. There's just no excuse for hiding this functionality. The Capture Cards screen should mention what keyboard accelerators it takes and not hide a crucial bit of functionality behind one. (And how come M only brings up TWO choices? Delete or Edit. Are you telling me that it was -so- important to separate these choices at all, instead of rolling them into each other? Or was it just easier to implement Delete if the configuration menu wasn't already onscreen? Right now, the -only- point of even -having- M in the interface (as opposed to Return, which calls up the menu even if you've never heard of M) is to enable one single option---Delete, since the only option is Edit, which is where you wind up if you hit Return. You might as well have just added a D option and left off the M, frankly.) [And you can't argue that M is usable everywhere. I just tried it in a very similar-looking list, namely the Input connections screen, where it does NOTHING. Yet typing Return there -does- get me the menu. Why the inconsistency? Clearly, Return works everywhere, but M doesn't---which is the user more likely to figure out by accident, and which is he more likely to remember?] By the way, each individual screen for the card should probably have a Delete button somewhere on it, too. It's safer if the user can look directly at the -complete- configuration of the card before deleting it; otherwise, if you've got multiple tuners (without which you're probably not going to be deleting a card in the first place), you have to COMMIT TO MEMORY the correct DEVICE NUMBERS before deleting one. It's another way to go wrong. And, given my other complaints about assigning new devnums causing the entries to rearrange their order in that listing, I don't even have any faith that I'd be deleting the right -card-, since their order kept changing. Lacking both of those, it just looked like someone had forgotten to even add this to the interface. Given all the other usability issues, can you blame me for making this assumption? Seriously, this is just getting laughable. Yes, and apparently not in the way you think. Currently, MythTV's configuration system looks like the Bad Example section of any book on user interface design. Class, let's review: (a) No automated setup for the most common actions. (b) No error-checking in critical data-entry fields. [Not even the -simplest- check for duplicate entry!] (c) Changes in some fields are thrown away without warning. (d) Any error in those fields---quite likely because of the above problems---causes problems that look like hardware failures. (e) Fixing those errors (apparently) breaks other functionality in ways that no non-developer user is likely to know how to fix. [For example, I'm still in the situation where my BE has mysteriously lost the ability to schedule recordings manually--- it just swallows the input. If I don't get a solution soon, I'm going to have to reinstall the entire backend. Good excuse to try Ubuntu, I guess.] (f) Old information is cached in hard-to-find places. [I deleted the fifth card---why is ivtv still bitching about it?] (g) Confusing, poorly-laid-out menu trees, with some options (e.g., several General menus) named identically but in different places and with quite different functionality. (h) Partially-overlapping configuration shared across two different programs, which no obvious division into which program is responsible for what. I must admit, I'm baffled by some of the apparent hostility here towards improving the user interface. Sure, call me abrasive, call me demanding, but don't carry
[mythtv-users] manual scheduling - no upcoming recordings
Date: Fri, 4 Nov 2005 16:45:55 -0600 From: Josh Burks [EMAIL PROTECTED] On 11/4/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: big snip Maybe you should ask for your money back... :) Maybe I should ask for my -time- back. Pity I spent all this money on this pile o' hardware over here... Seriously: You're apparently making the same it was free, so you have no right to complain argument that a lot of people have made about various problems in F/OSS and elsewhere. That denigrates the real problems that real people are having, not to mention insulting all the time, sweat, and tears that real people have already spent in building the system so far, -and- likewise the effort that the users have spent on getting the results to work. Sorry, but yours is a bogus argument, and you should know it. I'm trying to make this a better system. One way to do this is to complain, because otherwise problems can lurk for a long time without getting fixed. Not only does it raise the chances that somebody with commit privs will actually be willing to check in fixes, it raises the chances that somebody -else- who's also pissed-off about the state of the world will go and spend the time hacking to fix it, now that they know they're not the only one, that a fix would improve the lives of -lots- of people, and that their fix will be accepted into the tree. But by simply being snide -in public-, on the mailing list as opposed to just to me, you're evidently trying to interfere with an honest attempt to get things fixed. That makes you look foolish. Maybe you should get out of the way. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] manual scheduling - no upcoming recordings
Date: Fri, 4 Nov 2005 17:14:54 -0600 From: Josh Burks [EMAIL PROTECTED] Maybe you should take your complaints to the -dev list I've been reluctant to send mail there, since I'm not a Myth developer. Some developer groups are very protective of their list bandwidth, and I'm unsure of the etiquette in this case. My assumption has been that some developer on this list will forward, or that some developer (or at least some non-devo with a better sense of the etiquette) will tell me that I should send the buglist there (or that I should break it up into bite-sized pieces and check it directly into the bugtracker, or whatever). Given the amount of heat a simple list of bugs generated, I'm especially reluctant to drag it over there, unless the devos are more likely to pay attention and less likely to call me names for bringing up the issues in the first place than the (public!) reaction here. (The private reaction has been quite a different story, incidentally.) This is especially interesting in the light of ijr's recent snarky comment that I should only be sending mail to -dev if I want to start contributing in a useful manner. His attitude seems to be that pointing out where usability is bad is not, in itself, useful. Apparently I'm supposed to start checking in code without any discussion first. If that's not the case, or if I should really be sending mail to -dev and/or checking in bug - reports- (at least), I'd be happy to do that. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] manual scheduling - no upcoming recordings
Date: Fri, 04 Nov 05 18:32:16 -0500 From: R. Geoffrey Newbury [EMAIL PROTECTED] (b) I went into Schedule Recordings - Manual Schedule and wasted my time setting up 4 simultaneous recordings 5 minutes into the future, only to discover in Upcoming Recordings that it's claiming You haven't yet scheduled any recordings. WTF??? Yes. We are not alone... I'm sure. It did this to me a couple of times, just about midnight last night. That was in Manual Recording too. And ... Upcoming was empty. Hmm. Were you able to figure out any way of bringing back manual recording capability? I've probably got a full reinstall in my near future (probably on a different distro entirely), but I'd like to understand either how to recover from this, or what might have provoked the bug in the first place. (It sure sounds like both of us encountered this by reassigning /dev/videoN entries, though, which seems to indicate a bad bug lurking somewhere.) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] manual scheduling - no upcoming recordings
Date: Fri, 4 Nov 2005 19:39:54 -0400 From: Greg Estabrooks [EMAIL PROTECTED] Are there other commands besides M? Where are they documented? Various Howtos, keys.txt and god knows where else. That's kinda the problem :) Too many sources, some of which are dated. It's the problem of F/OSS in general, of course. You are imho expecting too much from a non commerical, non funded , we do it cause we enjoy it project done by people who donate their spare time too. There is no QA team, there are no professional UI designers, there is no focus groups to work out the best UI layout. Sure. I'm volunteering -my- time to make it better. Step one of that process is asking, Where is it broken? We now have a list of at least some places where it's broken. It is expected that users will have to read documentation. If you feel strongly otherwise then seriously, start taking your notes and working on what you feel improves the users experience. Noone is going to reject a patch that improves the usability of the application. As long as the code isn't horribly ugly, and follows the same style as the rest and fills a need then it will be considered. Good to hear. I don't (yet) have a sense of whether the current developers feel that fixing UI usability bugs fills a need; the public reaction here doesn't seem encouraging, but I obviously have not asked a group consisting only of those with commit privs. http://svn.mythtv.org/trac is where you can enter tickets on bugs (and how to reproduce them) along with the patches. Or you can post them to the mythtv-dev mailing list If it would be proper etiquette to break up the various bugs (especially those that are -clearly- Myth; some could be in Myth or in KnoppMyth the jury is still out) and either post them to -dev or enter them directly into the bugtracker, I would be more than happy to do that. It hasn't been clear to me whether a simple list of problems, -without- corresponding code to fix them, would be welcomed there. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] manual scheduling - no upcoming recordings
Date: Fri, 4 Nov 2005 20:04:50 -0400 From: Greg Estabrooks [EMAIL PROTECTED] Currently, MythTV's configuration system looks like the Bad Example section of any book on user interface design. Class, let's review: Then get to it, or try to encourage those who have the ability to do the work. But to do that would require a less YOU SUCK, EVERYTHING YOU DO SUCKS position. And while I understand that may not be your intent it is how your posts come off. It's certainly not my intent, and I appreciate your comments and those of some private posters who are trying to set me right on this score. But consider how this started: I got burned -really- badly (days of lost work) because of a bad UI. So I posted the reasons it was a problem. And then I posted a list of -other- UI problems that I'd written a week earlier, before I even knew I was about to be victimized by -more- bad UI :) Now consider the reaction: The -public- reaction was predominantly negative, mostly consisting of thinly veiled you're an idiot sorts of responses, and often eliding the most serious of the bugs and instead attacking the trivial ones. (E.g., no one yet has dared to argue that the UI -shouldn't- be checking for duplicate devnames in the Capture Cards menu, presumably because it's an indefensible position.) The -private- reaction was overwhelmingly positive, and extremely disturbing. I'm currently sitting on messages from at least half a dozen people who have -all- said in their messages that they are AFRAID TO SPEAK UP because they don't want the sort of public vilification that I've just endured. Either they don't want to deal with being the victims of a flamefest, or they're afraid of not being listened to when they want help later; their reasons vary, but they're all depressing. Users who are afraid to report bugs are a symptom of a very serious problem in the list's sociology. It's absolutely true that I became both more argumentative and more abrasive in responding to the public you're an idiot contingent, because their basic goal seemed to be to minimize even the importance of any of these UI bugs, e.g., to claim that there was no bug there in the first place and thus that patches for the behavior would be unwelcome. I have no idea if this opinion is shared by the majority of the development team. But I felt it was important, both because I'd personally gotten screwed by the UI issues, and because I had a large contingent of lurkers saying it screwed me too! but I dare not say anything in public!, to at least try to argue my side of the case as strongly as I could---namely that Myth has a usability problem that's (probably) not very difficult to fix, and that would benefit people widely if it were. At this point, with the exception of forwarding to -dev and/or checking-in bug reports on those bugs that seem definitely related to Myth (should I do either? still uncertain), I'm going to have to mostly bow out of this whole discussion, though. I've stated my case, I've at least gotten the UI issues that I've seen out on the table, and now I've got one and maybe two Myth boxes to reinstall (again, dammit!) in an effort to actually get a working system. It's been a couple of weeks now. With a little bit of sanity-checking in the UI, it could have been a couple of days. Yeah, I'm unhappy about this. -Then-, once I have a working system and some time to explore it, I might be in the situation of actually being able to submit patches for some of the UI issues. But until that happens, I can't even test anything I produce, so it would -clearly- be inappropriate for me to be submitting actual code fixes at this point. Thanks for your comments. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] manual scheduling - no upcoming recordings
Date: Fri, 4 Nov 2005 22:06:32 -0500 From: Isaac Richards [EMAIL PROTECTED] You got 'burned' because you didn't even _look_ at the capture card list after setting up any of your cards. All the device paths that have been setup are on that list. They're also in the input connections list. You didn't notice, is all. I -did- look. I failed to notice what was going on, especially since there are lots of 0's that are correct---just not those /dev/video0's. As I've said before, you're too close to realize that there's a whole lot of information whizzing by in this interface, and that -you-, as an expert, know exactly where to direct your attention to avoid problems. On the other hand, I, as nonexpert, did not. Ok, I'll dare. In some cases (if you wanted to setup the analog + hd parts of a hdX000, which doesn't quite work right yet), duplicate paths could be right. I see no reason to disallow this. Okay, then do you see no reason to have it put up a big fat warning saying, You're probably doing the wrong thing! Are you sure? That was my original suggestion, if you'll recall. That -one- check would have saved me a week of work, and (as it turns out) the list several 10's of K of messages talking about the whole thing. So far, though, you say that (in some future situation which doesn't even work yet) this should be allowed. Meanwhile, people right now have been screwed by the current situation. Seems to me that you should make the common mistake difficult, at the risk of making the unlikely future action require one additional keystroke. And I've gotten confirmation from a couple dozen people that you're off your rocker. Goes both ways. Sure does. Let's trade more numbers. It's fun. Sure, there are useability problems. It's good to hear some public acknowledgment of that. Your attitude is getting in the way of me responding to them, or even caring about what you're bringing up. If you want to fix them, learn how to act on a public mailing list. Fine. Don't publicly insult people if you want to appear reasonable. Yet every single piece of mail you've sent me so far as been insulting. As you say, Goes both ways. Learn how to reply to emails properly - your quoting is horrendous. Please explain. Learn how to state a problem _succinctly_. Do that, and everybody'll get along just fine. The succint statements got flamey responses. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] manual scheduling - no upcoming recordings
Date: Fri, 4 Nov 2005 22:43:55 -0500 From: Isaac Richards [EMAIL PROTECTED] On Friday 04 November 2005 10:21 pm, [EMAIL PROTECTED] wrote: Date: Fri, 4 Nov 2005 22:06:32 -0500 From: Isaac Richards [EMAIL PROTECTED] You got 'burned' because you didn't even _look_ at the capture card list after setting up any of your cards. All the device paths that have been setup are on that list. They're also in the input connections list. You didn't notice, is all. I -did- look. I failed to notice what was going on, especially since there are lots of 0's that are correct---just not those /dev/video0's. There's nothing on that page besides the pathnames + device types. Slightly difficult to miss. Yet apparently I did. People miss things sometimes, especially when they're new to a task, or when they're tired, or when they've had to do the same damned thing over and over again and might not be paying 100% attention, or when there are confounding influences (such as other things that were -supposed- to all have 0 on the end). All of these were certainly true of me. Having that cause a giant waterfall of peculiar bugs and a reinstall or two seems a rather extreme payback. As I've said before, you're too close to realize that there's a whole lot of information whizzing by in this interface, and that -you-, as an expert, know exactly where to direct your attention to avoid problems. On the other hand, I, as nonexpert, did not. Then why are you still arguing, if you think my opinion's not valid? Because I'm trying to convince you! Isn't that what an argument is -for-? [Okay, I admit, sometimes it's because you decided that getting-hit-on-the-head lessons were a stupid concept.] If I thought your opinion on WHAT A NEW USER EXPERIENCES -was- valid, I'd have shut up long ago. But not only are you a long way from that, you're the exact opposite---you -wrote- the very thing we're arguing about! How much farther away from (a) new user and (b) objectivity could you possibly -get-? (You know, there's a reason why they typically make the usability people and the programmers be -different people-. It's the same reason you don't let the bankers audit themselves. Plus, of course, there are different skillsets there, and mountains of research have shown that the typical coder is awful at figuring out what confuses users.) Ok, I'll dare. In some cases (if you wanted to setup the analog + hd parts of a hdX000, which doesn't quite work right yet), duplicate paths could be right. I see no reason to disallow this. Okay, then do you see no reason to have it put up a big fat warning saying, You're probably doing the wrong thing! Are you sure? That was my original suggestion, if you'll recall. That -one- check would have saved me a week of work, and (as it turns out) the list several 10's of K of messages talking about the whole thing. I don't recall your original suggestion. It was buried in a 10kb email that could have been stated in 2 sentences. I stopped reading after the first couple pages. Well, that's part of the problem, then. There is a -giant- list of problems in the interface just below paragraph 5. They're extremely specific. There are 10 of them. Each of them could be translated to a handful of lines of code. I guess you just didn't see any of them, and have been arguing in total ignorance of my point ever since the first post. Charming. [Then there's a list of 6 problems with the way forms work in general in this interface, right below that. I guess you didn't read those, either.] So far, though, you say that (in some future situation which doesn't even work yet) this should be allowed. Meanwhile, people right now have been screwed by the current situation. Seems to me that you should make the common mistake difficult, at the risk of making the unlikely future action require one additional keystroke. This is the very first time I've ever heard of someone assigning multiple capture cards in the setup program to the same physical device. [EMAIL PROTECTED] sent mail to the list just this evening saying that he had the identical problem of recordings not taking place, and that he suspected it was because he, too, had screwed up the /dev/videoN assignments and was probably going to have to reinstall to recover. So that's two just today. Maybe we should have a show of hands? I'm sure part of this is because multiple-tuner setups are less common than single tuners, of course. It could also be because people just assumed, Oh, I guess I was dumb and reinstalled (or maybe just fixed it in setup, if it didn't cause other problems later like what Newbury and I have been seeing), but didn't send mail saying, I was dumb in a way the computer could have prevented---which was the point of my mail.
[mythtv-users] Simultaneous recordings fail spectacularly---why? [part 1]
So does anyone---anyone at all---have -any- clues for me on why trying to record from multiple tuners crashes so badly for me? I've been dead in the water for a week on this problem, essentially, and it was only after many days of banging my head against the problem that I finally sent mail here. about it was yesterday. But nobody has (yet) offered any suggestions... Should I have asked on the -dev lists instead? This smells of some sort of ivtv initialization error, but I don't know for sure. Can someone at least tell me if some of my questions make sense and might help? Like, how do I know if the various alias lines ever really got used by the kernel? (The initialization is complicated enough, with a zillion scripts running in various places, and several methods (some of which claim that they're obsolete), that it's not clear to me; maybe I should just jam 'em into modules.conf even though it says don't edit me! and see? Are there ordering dependencies?) What happens if they -aren't- seen? Why is it that the first 250 seems to be initialized w/different bitrates than the rest? Is that a clue? How do I fix it if so? Does it matter that IRQ's were duplicated when ivtv inited the cards? Does -anyone- have a working KnoppMyth R5A22 setup w/more than one PVR-250 in the same machine? Should I drop back to A16 and see if it's more stable? I see mail just today saying that A22 used an SVN version; is A16 considered generally more stable? [I'd -really- like to avoid the effort of building from scratch from some other distro if I can possibly just get this debugged; that's many, many hours for me since I've never tried it before---and I don't even know if -that- will work!] (Yes, I'll ask these questions on the KnoppMyth forums, too, but some of the answers there to previous problems [which turned out to be real bugs, not failure to follow installation instructions] were more of a cargo-cult reinstall! reinstall! reinstall! flavor as opposed to how to actually debug the situation...) Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Simultaneous recordings fail spectacularly---why? [part 1]
Oh, and one more data point: I tried scheduling a 10-minute recording on ch2 for 11:30-11:40, and a 10-minute recording on ch4 for 11:35-11:45. The first 5 minutes of the ch2 recording are fine. At 11:35, -BOTH- recordings started recording ch4! (And the one that started earlier showed a periodic pixellation into large chunks, about one per second or so, while doing so.) It's like Myth (or something) is losing track of which card is which and is just always using tuner 0. [In fact, my first test like this showed ch4 in the second half of the ch2 file and ch4 in the ch4 file; my second test was to unplug the RF-in from all but the first of the 250's; -that- test also shows ch4 in the second half of the ch2 file, and a zero-length ch4 file. So it really and truly is looking like tuner0 got commanded to switch to ch4, which is just totally wrong.] Thanks! ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] Simultaneous recordings fail spectacularly---why? [part 1]
It's like Myth (or something) is losing track of which card is which and is just always using tuner 0. [In fact, my first test like this showed ch4 in the second half of the ch2 file and ch4 in the ch4 file; my second test was to unplug the RF-in from all but the first of the 250's; -that- test also shows ch4 in the second half of the ch2 file, and a zero-length ch4 file. So it really and truly is looking like tuner0 got commanded to switch to ch4, which is just totally wrong.] Whoops, forgot to add---the zero-length ch4 file started growing as soon as the ch2 file ended, e.g., in my offset-by-5-minutes staggered recordings, the first file got ch2 for the first 5 minutes, then ch4 for 5 minutes, then the second file started growing 10 minutes into the whole test (e.g., as soon as the first recording ended) and kept growing for another 5 minutes, ending up with the second file half the size of the first (even though they were, in theory, two 10-minute recordings that overlapped in the middle 5 minutes). So it's pretty clear that something's losing track of which card gets which channel and which file This behavior is identical whether all cards have RF-in, or only the -first- card has RF-in, e.g., I don't think the other cards are being used. Help? ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
