User talk:Wagnerrp

From MythTV Official Wiki
Revision as of 12:50, 5 December 2012 by InfoJester (Talk | contribs)

Jump to: navigation, search

To: Wagnerrp Re: iso-play.sh and edited HD Formats page

Thank you for your follow-up - I had a major WAF problem with DVDs and Blu-Rays not all working within the same MythVideo menu system and not working seamlessly across 3 myth frontends around our home. After finding an acceptable workaround for myself, I thought I should contribute it for others who may have the same immediate need. Being new to the Myth Wiki, I wasn't sure how to go about doing this. Apparently we were both editing the HD Formats page and "collided" - I didn't really understand what happened at the time. I took no offense to your undo and movement to the new page and understand your solid reasons. I prefer storage groups, but I just couldn't figure out how to work with them on the command line from within my script.

I saw you did some clean-up (thanks) - I look forward to more clean-up and hopefully a proper long-term solution to unifying Blu-Ray and DVD disk images. Direct support of Blu-Ray ISO images was a top priority for my situation. Thanks, Seschulz

Talk: find orphans.py

Thanks for editing my addition to Talk: find orphans.py. I had said that the script should remove deleted recordings from Previously Recorded. You removed the comment saying that it already does that. Interesting. Another bug in my system, I guess: I just spent several hours doing this by hand after find_orphans.py had done its thing. Hugh 05:16, 2 July 2012 (UTC)

When the script deletes recordings, it tells the backend to force it (as it will normally abort with no matching file), and it tells the backend to mark it as available to be recorded again. Ideally, the Previous Recorded (`oldrecorded` table) should exist as a permanent record of everything you have ever recorded in MythTV. When the script tells the backend to allow re-record, it merely flips the 'duplicate' bit for the matching entry in the table, causing further scheduler runs to ignore it for duplicate matching.
The other issue you are having trouble with is likely an otherwise harmless race condition. When the script runs, it grabs the entire contents of the `recorded` table, performs a full filesystem scan across all available backends, and then sorts out the missing entries. When you tell it to delete, it rapidly runs that list of recordings through the backend, and then repeats that process. You get a bunch of entries showing back up as it has pulled another copy the `recorded` table before the backend actually had a chance to delete those contents. By the time it is done filtering, displaying to you, and waiting for confirmation to delete, the backend has already done so. When it then gets around to telling the backend to delete, there is no database entry to delete, and the backend returns an error, causing the script to print its own error and recycle the list.
That's really useful knowledge. Should that be added to the description of find_orphans.py? In fact, I don't see the "duplicate" bit mechanism described in Duplicate matching. Where is it described? Hugh 14:18, 2 July 2012 (UTC)

RADIO BUG

hi, have seen it is a bug ... have you placed a bugreport, or shall i do so?

have checked mythtv-trac: i guess this bug is reported allready in #9824 --Sususu 10:34, 15 July 2011 (UTC)

Multirec configuration confusion ....

I think the paragraph that begins "The consequence of this is that live TV..." is unclear. Apparently MythTV as of Oct 2011 is not able to let LiveTV tune to channels from across multiple physical tuners when multirec is enabled. As LiveTV and multirec are both sensible defaults, it seems crazy that this situation persists. But the sentence "The alternative is to go back through after adding tuners, and add one more virtual tuner for each physical one" - this suggests there is a configuration solution to this problem, but I can't figure it out! I already have the max of 5 virtual tuners configured for each of the 2 tuners on my Hauppauge HVR-2200 (set up like this from scratch). Is the fix to go back into the configuration, and add one more virtual tuner to each card (ie .... 6 virtual tuners?) Surely not. I would love to help find a fix and sort out the documentation for this issue ....

- dan77g

When using LiveTV, your zapping is limited to those channels that can be tuned by your current tuner. This has nothing to do with multirec, but is just standard behavior of MythTV. This is to prevent potential scheduling problems where a user would unknowingly usurp control of a tuner from a recording (scheduled recordings always take priority). The problem with using multirec is that two users can be using two instances of LiveTV on the same tuner, or one user and one recording. When a tuner is in use, the other virtual tuners are locked to that multiplex.
The semi-kludgy work around described on that page is that you add your tuners sequentially, with 2-4 virtual tuners each. You then go back through and add one additional tuner for each, and set the frontend to avoid conflicts with recordings. Scheduled recordings will work down from the top of the list, looking for the first tuner capable of tuning that channel. Since the virtual tuners were added sequentially, it will automatically prefer an in-use tuner over grabbing a fresh tuner, potentially to record on the same multiplex. LiveTV, with that setting, will instead work up from the bottom of the list, with each new session getting its own fresh tuner. However, as before, each tuner being used by LiveTV means a potential conflict where you may no longer have sufficient tuners for your scheduled recordings.

Removing completed feature requests.

Hi Wagnerrp, Just noticed that you removed[[1]] a feature request and commented that it can now be done with mythccextract. However if I search the wiki for mythccextract I get no hits. Would it be better to at least create a new page for mythccextract, paste in the request and add a quick comment to say that mythccextract can do this. Maybe mark/label the page for further editing by someone else, but then people would at least be able to find out that MythTV is now capable of this functionality.

The best option would be to document it in the manual somewhere, with a page describing its use. The feature request pages are really too large and hard to read though as it is, leaving large numbers of 'closed' items just clutters it that much more.
Firstly thank you for all the work you do to tidy up the wiki. Without you this site would probably be a mess of spam and bitrot. I agree that the best option would be to document it in the manual, but that isn't what you did and nor would I expect you to. I just thought that it would been worth creating a bare basic page that acknowledges the existence of the feature otherwise someone else might end up making the same suggestion.
I want to say thank you for your work on this wiki, too! As a long term MythTV user (since 0.14) it became one of my favourite websites. I have no deep knowledge of wikis, but lamp and website programming in general. So I have a suggestion for the mythtv wiki: there are many anti-spam tools out there which would greatly improve reading "Recent changes". Sadly, there is a lot of spam account creation (and your deletion) entries which keep the viewer from having a quick overview what valuable wiki entries really have been added or changed. Getting rid of those spamming lines would make this valuable MythTV resource even more valuable :) - reznor
Heh. I've been meaning to do something more permanent about that, but haven't gotten around to it. A while back, I added a simple filter that would block anyone from using anonymous mail services like Mailinator, and that knocked out most of the spam we had been getting. Now everything seems to be coming from domains like Hotmail, Yahoo, or to a lesser amount Gmail. I can't very well block those. On the other hand, even if I never touched those new accounts, less than five percent would ever even bother authenticating, and chances are don't even have access to the email address they used to sign up with. We're nearing the 20k user mark, but less than a quarter of those have authenticated, and then only some 3600 have ever made a single edit.

Editing the manual

Hi. The history says you've edited the manual lately and I'm asking if you're the one referring to yourself in first person there (User Manual:About). I'd like to contribute some more - I've done some basic edits already. So I'd like to know a few things about "style" in terms of voice (first/third person) and any other tips for consistency. Thanks.

Nope. For that page in particular, the only changes I made were the addition of the right side bar, and the removal of an old named page in favor of a proper User: page. For future reference, you can use the radio buttons on the left side of the history page to select a range of edits, such as this. Try to stay in third person if at all possible. Thanks for the edits!

Mistakenly blocked

Hi Wagnerrp. You have blocked my account 'InfoJester' (Block ID #4943 04:11, 11 November) with a comment of spamming. I hope this is a mistake as I don't think I've even added anything yet. Please can you remove the block as I'd like to contribute.


Thanks Wagnerrp. These things happen, it's no big deal. I could see that you were having to make loads of blocks so it's easily done.