Wednesday, April 30, 2008

Quick and Dirty TV Tuner for VLC

I'm partial to mplayer for most of my video and other media playing, but found myself using VLC a lot recently to verify that a V4L (Video for Linux) compatible 'PVR' (Personal Video Recorder) card had proper driver installation and was functioning correctly. I was frequently picking 'File / PVR' and entering

pvr:/dev/video0:channel=0:norm=ntsc:size=640x480:frequency=561250

something I find as awkward to type in as you probably would also. This sets the PVR card to 'channel' zero, the TV tuner, sets it for NTSC broadcast format, a typical screen pixel size, and a frequency from the standards that tunes to the local broadcast channel 28 (KCET, Los Angeles, CA). Fumbling around some, I figured out how to save this as a playlist, and since forgot that process.

But what I did remember was the format that the playlist was in. I used that sample playlist file, the information at http://en.wikipedia.org/wiki/North_American_broadcast_television_frequencies and created a 'TV tuner playlist', stashed online at http://www.lafn.org/~aw585/na.tv.channels.pls

The first few entries are what I want for a default channel, both the 'proper' and 'actual' frequency (perhaps the card or Wikipedia still needs some adjustment), entries for S-Video and Composite settings for the PVR card, and then settles into the standard North American channels in proper order. Using information online at Wikipedia it can of course be changed to personal/local needs. Someone more knowledgable about TV technology can probably suggest improvements on the playlist/table presented.

You can select from the VLC control panel 'Settings' / 'preferences' / 'playlist' and enter your local name of the file ('.vlc/na.tv.channels.pls' in my case, stored in the .vlc subdirectory of my home direcory) for the default playlist and save to get the first entry to start on VLC startup.

This leaves a lot to be desired as an interface, but you just click on the previous/next stream graphics (double arrows) to move up and down the North American TV bands. It sometimes seems to need double clicks to get past some 'humps' going down the bands past stations, but it is functional as a quick hack!

Tuesday, April 29, 2008

Ubuntu Battle Prep

I've ended up doing several Ubuntu installs lately, and find I have to go through a preceedure to get some favorite tools installed while trying to dig out information and solve problems.
  • Edit /etc/apt/sources.list. Make a second copy of all the default sources installed, and change on all the copies 'http://archive....' to 'http://us.archive....', to give some quick and easy extra depth to the available Ubuntu .deb package archives.
  • Immediately 'sudo aptitude update' to ensure access to the latest packages.
  • edit ~/.bashrc, including lines with:
    • set -o vi
    • export IRCSERVER='irc.freenode.net'
    • export IRCNICK='mr_dallas'
    • alias realias='vi ~/.bashrc ; source ~/.bashrc ' ;
  • sudo aptitude install screen lynx-cur tinyirc ckermit gkermit
  • edit /etc/lynx-cur/lynx.cfg, adding 'TEXTFIELDS_NEED_ACTIVATION:TRUE' (this and the below changes to lynx options move lynx from klutz to 'thought control' mode for rapid googling of answers.)
  • edit /etc/screenrc, adding
    • 'escape ^Oo' # this avoids a lot of conflicts of screen with other programs
    • 'startup_message off' # for less noise when starting screen
    • perhaps beefing up 'defscrollback' to maybe 4096.
  • startup Lynx, go into options ('o')
    • change it to advanced user mode
    • turn on 'vi' keymode
    • For the number pad set 'Links and form fields are numbered'
    • check the box to 'save options to disk' before accepting changes
    • Go to and bookmark my private portal page, where I have many usefull links and forms.
This doesn't by any means duplicate all my environment on my personal machine, but it gets some simple tools that help quickly hunt for answers and solve problems available.

Saturday, April 5, 2008

Open(ing) ID(=)

The other day I was editing a personal, private portal page I've created for my own use. It has a lot of features I've been experimenting with such as accelerated login to some services by way of simplified login forms, search engine forms with a single search field set up so just hitting enter in the field starts the search etc.

I was checking the proper HTML for internal fragment links, recalling that a quick reference book I had the form '<A name="....' and some examples I had on another web page had '<A id="....'. This triggered a chain of thought when I was looking at another page, and noticed that 'id="'s were sprinkled all over the place in the HTML - if you don't believe me, just take a look at the source for http://en.wikipedia.org. So - could I tack #xxx's on the end of a URL and have it go to some spot corresponding to the arbitrary piece of html in a web page.

The answer for Lynx was yes, and some checking seemed to indicate the same held true for Firefox as well. Everything up to this point may seem obvious to someone with more in depth knowledge of HTML. My next thought though, was that I'd like to make it easier to bookmark a page with a more specific location added as an HTML fragment to the address.

A few hours of work on the idea turned out a modest sized script that can be used as an EXTERNAL for Lynx. It strips out the name= and id= fields of a web page, reformats them in to #<name> #<id> fragments on the URL and pumps both lists wrapped with appropriate HTML into Lynx for browsing/bookmarking. When you're finished, just exit Lynx to resume where you left off. An example of what gets kicked out when you run it on http://www.google.com:

This may not seem too important when used on such a deliberately simplified page, but it makes it much easier to bookmark the search field for http://en.wikipedia.com as an example. One weakness of this is that since most browsers make it relatively hard to bookmark such a specific location in a page, these are probably more subject to change with the whim of the HTML coder and/or their coding tools.

'name=' didn't seem to be noticed by the browsers I checked with, but was used in the example in the reference guide I looked at, so it may change in the future (or changed in the past.). I left it in the script. Some example pages I checked set 'name=' and 'id=' the same on many HTML elements. Glancing through the quick reference on HTML I found several elements that specificly allowed 'id=' attribute: <A>, <DIV>, <LAYER>, <PARAM> and <SPAN>. But on closer inspection, I found many listed a '%coreattrs', and when I found that in the guide it included besides 'id'; 'class', 'style', and 'title'. %coreattrs pretty much busts wide open the elements that can have 'id' attributes - <FORM>, <UL> etc. I used this to simplify the HTML in my portal page that triggered this discussion, rolling fragments for internal navigation into lists that group related links/forms.

This also is an example of a subject I've railed about in person on occasion, that web pages are subject to different interpretations ("renderings") depending on circumstances and the goals of the 'viewer'. This extreme view provides a list of everything I can think of that could be linked to on a web page.

I've pitched the script temporarily at: http://www.lafn.org/~aw585/microBkMrk

7 April 2008 Addendum:

    A few other points about this topic:
  • Since I suspect that the fragment addresses will be more subject to change than a base address for a page, it may be more important to monitor pages bookmarked/linked to in this manner for changes by whatever means.
  • Conversely this is yet another way to view of a web page that can be hashed/'fingerprinted' to monitor for changes in the page.
  • It might be usefull to dump out a few more attributes and maybe the element they are part of for the IDs and NAMEs, to provide a more human readable overview of the page, many of which are generated by tools that provided the author with a very abstract/high level relation to the html. In other words, he never actually saw the html, and there was no thought to anyone needing to look at it. This provides one view that summarizes features of the page. There are probably quite a few features that could be added to this tool.
  • From an accessability/usability view point, this might save repeated thrashing with a page. Someone might fight it out or get help a first time, but then by finding a precise spot they can either bookmark, link to or just go to with a #<fragment> address, they can effectively reuse the work of initially understanding how to navigate the page. This isn't neccessarily a result of a poorly designed page, but could in some instances merely be because of the nature of the information being presented or asked for. The full implications of this remain to be seen.