Robin Gareus

Topic::installation

rgareus — 2012-02-21T12:18:03+00:00

Tagged Items about installations, exhibits, and applied hard/software:

Page	Date	Tags
breedr	01.10.2008 18:11	news, FLOSS, installation
frontera	09.07.2008 21:27	FLOSS, Installation
Occupy Wall Screens	11.12.2011 00:03	installation, news, video
picnic08	21.09.2008 22:53	news, installation
World Skin - a Photo Safari in the Land of War	28.01.2010 17:34	video, installation, audio
jrec2	23.06.2009 11:27	JACK, FLOSS, MUSIX, INSTALLATION
Open Sound Control Utils	23.06.2009 11:27	FLOSS, INSTALLATION
PanJack	11.06.2008 12:31	FLOSS, JACK, MUSIX, installation
xjadeo	23.06.2009 11:27	JACK, FLOSS, VIDEO, INSTALLATION
The Other Side	19.04.2009 09:39	Bookmark, floss, installation
the Frontera Project	16.04.2008 15:05	FLOSS, Video, Installation
InOut	20.02.2009 15:07	development, installation
Video synchronization - Screen-shots	11.02.2008 01:37	Video, Installation, Development
VGA to SCART	23.06.2009 11:27	video, development, installation

Video synchronization - Screen-shots

rgareus — 2012-02-20T10:49:53+00:00

This is about testing and debugging Video/Screen synchronization.

The problem is simple and common: You play a video file at a given framerate (eg 24 fps, 25fps or 29.97fps) while your Screen is refreshed at a different rate (eg 60Hz, or 75 Hz or 85Hz).

Test Setup

video files with alternating black and white frames (at different framerates)
cable from VGA (green-luminance) to soundcard (audio-in)
yass (yet another scrolling scope)
different video players (mplayer, xine, xjadeo) in fullscreen mode

For the black video frames the signal will be zero during the whole cycle. For white frames it should be about 1V, with the start and end of each frame marked by a short (~1ms) zero.

This may give you an idea: smoothly playing a 25fps file of alternating black and white frames on a 75Hz screen: 3times black ; 3 times white frame with vertical sync.

The setup was done on one machine with two screens (one for monitoring, and the 2nd screen used as probe displaying the video). Using a single machine allows for software to measure the delay between a requested screen update and resulting signal (after compensating the audio-interface's latency). (Note that not all grafic boards allow DRI sync if two screens are in use)

…

Video, Installation, Development

IHM -- recursive semantic hypermedia archive

rgareus — 2012-02-20T10:48:02+00:00

Robin Gareus

CiTu, Université Paris 8; linuxaudio.org

Introduction: The Problem

IHM needs a spiffy media archive :)
There is no appropriate non-commercial solution.
joomla or drupal could be customized; yet that path would require non-sustainable development effort.

Intro.: Motivation / Use-case

Why another content-management system ?

Content means “some sort of information”, management in this context means “doing something with it.”

Most of the CMS are web-site revisioning systems with emphasis on social networks.

We want a system to contain abstract items or objects (i.e. image, article, movie, person, location, comments,..) and be able to define semantic relations between them.

Intro.: Collaborations (1/2)

Potential applications, existing projects, collaborations:

IHM - archive about history of man-machine interfaces
TheArtCollider - platform for connected creation (CiTu, Paris8)
MMDB - MyMovieDatabase (GNU project)
Ozalid - upcoming social network and archive of the Bibliothèque nationale de France
zeega.org - interactive documentaries and new forms of storytelling (Meta-Lab, Harvard)

Intro.: Collaborations (2/2)

Freesound.org - collection of audio-samples
newscoop/superdesk - newsroom production system (sourcefabric.org)
airtime - radio station system (sourcefabric.org)
mmTeX - fan-fiction layout and book publishing engine.

Intro.: Goals / Outline

Complete language-set to define relations
Modular system (extended by plugins)
Publish/subscribe architecture
Social network integration
Pluggable front-ends:
- n-dimensional navigation, timeline
- interoperability with existing authoring tools, apps and data-sets.
- integrated XHTML engine

Implementation: Data Model

The datamodel is a language based on triplets:

“Subject” + “predicate” + “Object”

Where subject and objects are an noun for an item/thing/frame/object and predicate is a verb.

Both, items and predicates are modular types and each of them may optionally have have dynamic attributes or adverbs.

Impl.: Data Model Example

“Mona Lisa” + was presented [from date to date] at + “the Louvre [website]”.

“Mona Lisa” + was authored [on date] by + “L. da Vinci.”.

Legend:

“subject, object”
+ predicate +
[attribute]

Impl.: References, Edges

Each item in IHM has a canonical resource-URI (aka. UUID) - which can be used to universally reference the content (similar to a permalink).
Edges are directional (parent/child) links between two resource-URIs using a predicate.
A matrix defines the potential relations.

Impl.: Data Types and Relations

http://theartcollider.org/ihm-test/?viz=vis_form_admin_typematrix

Impl.: Technical Specs

PHP/JavaScript/XHTML5, REST-API
Model/View/Controller
OAuth/OpenID for access control and authentication.
Atom/XML is the main data-format for content.
uses existing RDF templates (SOAP, DOAP, FOAF, etc)
modular system: the layout/architecture is defined in the core but the actual visualization, rendering and [interaction + graphic] design is handled by plugins.

Impl.: Data Aggregation

Each object may be aggregated or synchronized with an external resource URI.
Items may reference read-only sources (media archive on disk, 3rd party information) - synchronisation.
Changes to the data-set are published (push) and can be subscribed to. Asynchronous updates.

Prototype: Demo

Site: http://theartcollider.org/ihm-test/

API: http://theartcollider.org/ihm-test/api_rest.php

Prototype: What's missing

Proper front-end (web and interaction design[er])
- Item visualization
- Project specific customizations
Backend-parts:
- Authentication & access-control
- Pub/Sub API
- Query filtering on edges.
- …
Community management

Prototype: Outlook, Roadmap

Publicly usable prototype: after x-mas
Freeze APIs: spring 2012

Open LDAP Server

rgareus — 2012-02-20T10:12:21+00:00

mirored from http://www.metaconsultancy.com/whitepapers/ldap.htm

It is often convenient to share system information among workstations. For example, users like to be able to log in to multiple machines with the same password; this requires that the machines share the data conventionally stored in /etc/passwd and /etc/shadow. Using NFS usually isn't an option, since that would share all of /etc/, and we may well want some things configured differently on each machine. NIS used to be a common answer to this dilemma, but LDAP (Local Directory Access Protocol) databases, being more flexible and scalable, have now become the preferred solution.

LDAP databases are object-oriented (as opposed to relational, for those of you familiar with such beasts). An LDAP database is filled with objects, each of which has associated attributes. Here, for example is a typical object representing a user account.

dn: uid=john,ou=people,dc=example,dc=com
cn: John Doe
uid: john
uidNumber: 1001
gidNumber: 100
homeDirectory: /home/john
loginShell: /bin/bash
objectClass: top
objectClass: posixAccount

Each object has a DN (distinguished name) attribute that identifies it uniquely. Each object is a member of one or more object classes, which determine which attributes it may and must have, according to a well-defined schema. Objects in an LDAP database are organized into a tree hierarchy, based on their DN. By tradition, the organization example.com uses dc=example,dc=com for its root object (but nothing enforces this tradition). Below the root are objects representing different organizational units, such as people or hosts. The children of these objects are the people and hosts themselves.

We use OpenLDAP, because it's free and works for us. The rest of this whitepaper describes how to set up an OpenLDAP server to hold your organization's user data.

Installation

slapd is the name of the OpenLDAP LDAP server daemon.

apt-get install slapd ldap-utils

Basic Configuration

The basic configuration file for slapd is /etc/ldap/slapd.conf. The file can be loosely divided into two parts: an operational part, describing how the slapd daemon does its job, and a database part, describing the LDAP datastore (or datastores; a single slapd can serve multiple LDAP databases).

Consider first the operational part. A simple example follows.

//slapd.conf//

# schema
include      /etc/ldap/schema/core.schema
include      /etc/ldap/schema/nis.schema
schemacheck  on

# run files
pidfile      /var/run/slapd.pid
argsfile     /var/run/slapd.args

# timeout (in seconds) for dead connections
timeout      60

The schema part loads files which describe which sorts of objects may and must have which properties. Schema files are traditionally stored in the /etc/ldap/schema/ directory. Our example includes only the two most common schema files, but you may well want to load all the schema that ship with OpenLDAP, and even add some more of your own.

By declaring schemacheck on, we tell slapd to require that objects conform to schema files before it accepts them. You should always maintain this requirement, as it helps protect you against accidental errors when updating your database.

The database-specific part of the configuration file tells slapd the database root DN, and how and where to store the data. Here is a simple example:

# ldap database
database     ldbm
suffix       "dc=example,dc=com"
directory    "/var/lib/ldap"

Our example stores data using an embedded database which stores files in /var/lib/ldap. The embedded database (ldbm) option is by far the most common backend, and is the only one we will discuss here. OpenLDAP allows other options, but they are much more difficult to configure.

Securing OpenLDAP

OpenLDAP offers several mechanisms to protect the security of the data it stores. Here we discuss password hashing, access control lists, and connection encryption.

The userPassword attribute is special. Clients use it to authenticate themselves to slapd, and slapd stores it in hashed form. (A hash is a transformation which is simple to do, but difficult to undo.) When a user types in a password, it is hased and compared against the stored hash, rather than being compared directly against a stored cleartext password. Since the cleartext password is not stored anywhere, this trick (which is also used by /etc/shadow) keeps your passwords safe even from someone who has broken in to your LDAP server. You can specify the hash algorithm you want slapd to employ in slapd.conf.

//slapd.conf//

# password hash algorithm
password-hash {MD5}

We like MD5, since the mechanism is both secure and widely employed. SHA and SSHA are also secure, but less widely employed. CRYPT is the most widely employed hashing mechanism in the Unix universe, but is known to be insecure and should be avoided.

It is important to define which users are allowed to read and write which object attributes. These “rights” are defined by ACLs (access control lists) in slapd.conf. Here is a simple example for account information.

//slapd.conf//

# lock down passwords
access to attribute=userPassword
      by dn="cn=admin,dc=example,dc=com" write
      by self write
      by anonymous auth
      by * none

# allow users to write some stuff
access to attribute=loginShell,shadowLastChange
      by dn="cn=admin,dc=example,dc=com" write
      by self write
      by * read

# everything else is read-only
access to *
      by dn="cn=admin,dc=example,dc=com" write
      by * read

It is easy to make security mistakes when setting ACLs. For example, if you give users write-access to uidNumber, they can set it equal to zero to turn themselves into root. Consider carefully the security implications of each access privilege you grant.

By default, LDAP data, including passwords being transmitted for authentication, move across the network in the clear. To protect yourself against eavesdroppers, you should take the simple step of configuring slapd to offer encrypted sessions, and configuring your clients to use them. To enable encrypted sessions, use the openssl utilities to generate a key and corresponding public certificate, and tell slapd to use them for encrypted sessions. slapd.conf

TLSCertificateFile /etc/ldap/ldap.example.crt
TLSCertificateKeyFile /etc/ldap/ldap.example.key
TLSCipherSuite HIGH:+MEDIUM:!LOW

It is important that the CN (common name) on the certificate be exactly the FQDN (fully qualified domain name) which clients use to contact your LDAP server. For example, if your server is named ldap.example.com, that should be the certificate CN, and clients should connect using that name, not the corresponding IP address. Such a restriction is only necessary for encrypted sessions.

The certificate key file should be readable only by the user as which slapd runs (for the Debian package, this is root).

# chmod /etc/ldap/ldap.example.key 0700

OpenLDAP Utilities

There are two classes of utility programs which allow you to modify your OpenLDAP database. The slap* programs (slapadd, slapcat, and slapindex) read and modify an LDAP database by operating directly on the files in /var/lib/ldap. To avoid database corruption, they should be employed only when slapd is not running. The ldap* programs (ldapsearch, ldapadd, ldapmodify, ldapdelete, and ldappasswd) read and modify an LDAP database by interacting with the slapd server. They are essentially very simple LDAP clients. They can only be employed when slapd is running.

offline (slap*) utilities

The slapd* utilities accept ldif files as input. ldif files are just flat textfile lists of objects, with attributes indicated in a key: value format, one per line. Here is an example of a simple ldif file that creates the skeletal structure of a simple LDAP database.

/tmp/example.ldif

dn: dc=example,dc=com
dc: example
o: example.com
objectClass: top
objectClass: dcObject
objectClass: organization

dn: ou=people,dc=example,dc=com
ou: people
objectClass: top
objectClass: organizationalUnit

dn: cn=admin,dc=example,dc=com
cn: admin
userPassword: secret
objectClass: top
objectClass: organizationalRole
objectClass: simpleSecurityObject

Getting these objects into the LDAP database is easy.

# /etc/init.d/slapd stop
# slapadd -v < /tmp/example.ldif
# slapindex -v
# /etc/init.d/slapd start

Note that we shut down the database before running slapadd. Note also that we ran slapindex after entering the data to update the index files. While indices are automatically maintained when changes are made to a running database (e.g. using ldap* commands), they must be updated “by hand” when changes are made directly to the database files; this is accomplished by running slapindex.

The slapcat command is the “opposite” of slapadd. It extracts the contents of an LDAP database into a ldif file. To make a backup of your LDAP database,

# /etc/init.d/slapd stop
# slapcat > /tmp/example.ldif
# /etc/init.d/slapd start

Be sure to store the extracted ldif file in a safe place, since anyone who can read it can effectively read all the data in your LDAP database. Since making this backup requires you to shut down your slapd server, backups of large, mission-critical LDAP databases should be made from a replicating database (see slaves section below) designed specifically for this purpose.

It is often necessary to use slapadd to create the skeletal structure of a new database, since when a database is first created, it does not contain any administrator object that has permission new objects. Once you have used slapadd to overcome this chicken-and-egg problem, though, you will probably want to use ldap* commands or even a GUI LDAP client for further database modifications.

online (ldap*) utilities

The ldap* utilities are easily installed on a Debian computer.

# apt-get install ldap-utils

Keep in mind that these utilities need not be run on the LDAP server.

The file /etc/ldap/ldap.conf contains the basic configuration information necessary for the ldap* utilities to know with which LDAP database you want them to interact. A simple example follows.

/etc/ldap/ldap.conf

URI  ldap://localhost
BASE dc=example,dc=com

The URI directive specifies the LDAP server to use; in our example, we are working on the LDAP server itself. The BASE directive specifies the DN of the root node of the database.

The most common way to interact with an LDAP server is to read data stored in it. The ldapsearch command allows you to do this from the command line. For example, to obtain the attributes of objects for which cn=admin,

# ldapsearch -x cn=admin
dn: cn=admin,dc=example,dc=com
objectClass: organizationalRole
objectClass: simpleSecurityObject
objectClass: top
cn: admin

You can use * as a wildcard in your search. To get every object in the database, use

# ldapsearch -x objectClass=*

You can use the ldapadd command to add objects to your ldap database. Like slapadd, ldapadd uses LDIF input syntax. Unlike slapadd, ldapadd interacts with slapd via LDAP to make its modifications. Therefore it can be used across the network, can (in fact must) be used while slapd is running, and allows background tasks such as schema checking, indexing, modification time stamps, and replication to be handled transparently by slapd instead of by hand. For example, to add a user account, we prepare an LDIF file

/tmp/user.ldif

dn: uid=jdoe,ou=people,dc=example,dc=com
uid: jdoe
cn: Jane Doe
uidNumber: 1001
gidNumber: 100
homeDirectory: /home/jdoe
userPassword: password
loginShell: /bin/bash
objectClass: posixAccount

and then upload it to the running ldap database

$ ldapadd -x -v -D cn=admin,dc=example,dc=com -W < /tmp/user.ldif

Note that we bind as the administrator in order to gain write privleges.

The ldapmodify utility allows you to modify the attributes to existing ldap objects, and the ldapdelete utility allows you to delete an ldap object completely.

The ldappasswd utility, the last of the ldap* suite, is used to change userPassword attributes. Don't use ldapmodify to do this, since that will write a value to the attribute directly, bypassing the hashing specified in slapd.conf. For the administrator to change Jane's password,

$ ldappasswd -x -v -S -W -D cn=admin,dc=example,dc=com uid=jdoe,ou=people,dc=example,dc=com

Migration Utilities

PADL software makes available a set of migration tools which ease the transition from a system using flat files (/etc/passwd, /etc/group, /etc/hosts, /etc/networks, /etc/services, /etc/protocols) to a central directory server. You can download these tools from the PADL site, or install the Debian package

# apt-get install migrationtools

which places them in /usr/share/migrationtools/.

To use these tools,

# cd /usr/share/migrationtools
# ./migrate_passwd.pl /etc/passwd /tmp/passwd.ldif

Performance Tuning

LDAP databases take a beating. Every email, every login attempt, every directory listing (ls) on any machine at your site can result in a lookup. Fortunately, there are a number of things you can (and should!) do to increase OpenLDAP's performance.

Begin by generating indices, which are database tables that can be used to track down a record much faster than by looking though the entire database.

/etc/ldap/slapd.conf

index objectClass eq,pres
index uid,uidNumber,gidNumber eq,pres
index mailLocalAddress eq,pres

If monitoring (e.g. using top) indicates that slapd is often consuming a significant fraction of your CPU time, you are probably missing a useful index. LDAP lookup should be I/O-bound, not CPU-bound.

Try to give slapd enough memory to hold all or most of its data in memory. The cachesize directive specifies how many attribute values are cached in memory. The dbcachesize directive specifies the size, in bytes, of the space allocated to store database files in memory. The defaults for these numbers are almost never large enough. For our small organization, I use

slapd.conf

cachesize     10000
dbcachesize   1000000

Ideally, cachesize is as large as the total number of entries in your database, and dbcachesize is as large as all the files in the /var/lib/ldap directory. At larger sites, you may find that your LDAP server needs quite a bit of memory in order to attain these objectives.

Make sure you are not writing more to your log files than you need to. If you can get away without an audit trail, set loglevel to 0. If you really need an audit trail, set loglevel to 256, and be sure to use a - in /etc/syslogd.conf to allow log entries to be written asynchronously.

Minimize lookups by running nscd on your client machines. Consider upping slapd's threads variable to 64 or 128.

At very large sites, you may find that your lookup throughput is still insufficient, even after you have taken all these steps. At this point, you may have to invest in more or better hardware. If your throughput is disk I/O bound, consider dedicating a fast, SCSI disk just to /var/lib/ldap, and mount that disk with the noatime option in order to cut down down on access overhead. If your throughput is network I/O bound, make sure you have a fast ethernet card. Check that the packet collision rate suffered by your LDAP server is still low (say 5% or less); if not, you need to upgrade your network. Finally, consider setting up a number of dedicated LDAP slave machines, and assign the number of clients to each slave that produces a load it can handle. Instructions for setting up LDAP slaves are presented in the following section.

LDAP Slaves

An LDAP slave is an LDAP server whose contents mirror the contents of its LDAP master. Slaves respond to read requests themselves, but when faced with a write request, a slave refers the client to its master. Any change to a master database is propagated to its slaves immediately and automatically; this process is called replication.

LDAP slaves are useful for load-balancing; distributing client requests among a number of slaves can keep the master from getting hammered. LDAP slaves are also useful for automatic failover. Many LDAP clients can be configured to fall back to a second LDAP server if the first does not respond; by setting a client's fall-back server to be an LDAP slave, you can keep your system running even if your LDAP master crashes.

Setting up a master-slave relationship between two LDAP servers is not difficult.

slapd.conf

replogfile        /var/lib/ldap/replog

replica host=slave.example.com:389
      binddn="cn=admin,dc=example,dc=org"
      bindmethod=simple credentials=secret

slapd.conf

updatedn          "cn=admin,dc=example,dc=org"
updateref         ldap://master.example.org

DokuWiki Publish/Subscribe

rgareus — 2012-02-19T20:02:53+00:00

Ideas on Server to Server communication to synchronize dokuwiki content.

News

took the detour to implement an oAuth plugin. — 22.10.2008 13:00
added a development roadmap. — 01.09.2008 12:30
coffee break - installed a trac for this project. — 31.08.2008 15:18
Just received and processed(!) the first XMPP notification. dokupubsub alpha-1 is out. — 31.08.2008 13:53
I've started work on a prototype DokuWiki plugin. Download a devel-snapshot. dokupubsub interacts with idavoll to interface to the XMPP world. — 29.08.2008 15:02

dokupubsub

The plugin code is still flux. You can test the alpha devel snapshot or have a look using the source-code-browser. You can check out the code with

git clone git://gareus.org/dokupubsub

Note: This plugin is not safe to run on any internet-connected site just yet!

Additional to installing the plugin into DokuWiki's lib/plugins folder, you'll need to run jabberd2 and idavoll (setup notes) on localhost with the webserver:

sudo twistd idavoll-http --jid=localhost
tail -f twistd.log

The dokupubsub plugin writes debug info to /tmp/PubSub.debug. Subscriptions (automatic wiki-page update notifications) are restricted¹⁾ to the ext: namespace - adjust the ACL accordingly. Currently I'm testing subscribing to publications on localhost using the same DokuWiki.

After editing a page (with the web-interface) it will be published to the gateway; the xmpp uri of the publication is saved with meta-data and added to the HTML header as <link rel=“alternate feed” href=“xmpp:..”/> for discovery. Notifications from the gateway are handled with a custom do[dokubookmark]=notify RPC handler inside the plugin.

There is no PubSub admin interface yet. To subscribe to changes you'll need to make a request specifying the originating XMPP uri and the destination wiki-ID eg:

curl -d "what=ever" "http://localhost/dokuwiki/doku.php?do%5Bdokupubsub%5D=subscribe&id=wiki%3Astart&nodeid=xmpp%3Alocalhost%3F%3Bnode%3Dgeneric%2Fbe096541-c728-42f8-b0f6-f330a86b5ec7"

or equivalently:

curl -d "nodeid=xmpp:localhost?node=generic/123456789-abcd" -d "wikiid=start" "http://localhost/dokuwiki/doku.php?do%5Bdokupubsub%5D=subscribe"

example xmpp-url discovery - see /tmp/PubSub.debug

curl -d "url=http://localhost/dokuwiki/start"  "http://localhost/dokuwiki/doku.php?do%5Bdokupubsub%5D=discover"

For testing, you can fake notifications by saving an Atom-entry document as file /tmp/ps.xml and run

curl  -d "@/tmp/ps.xml" "http://localhost/dokuwiki/doku.php?do%5Bdokupubsub%5D=notify&id=wiki%3Atest"

Change the id=?? to match the wiki-page-id on the subscribing site.

earlier ideas and brainstorm

About

Motivation ranges from adding features such as DokuWiki mirror, backup and decentralized load-balancing solutions to semantic web communication and data-portability.

Kludge solutions (like dokursync) work fine for smaller sites but there's need for improvement on scalability and offering web-standards.

Outline

I envisage a subscription and a publication plugin for DokuWiki, making use of existing infrastructure (eg. Atom and raw data export). A mechanism to distribute locks may be included in either or will be implemented in an optional standalone plugin.

Current ideas include using a XMPP ↔ HTTP gateway and or the WikiRPCInterface2. Then again, using a custom RPC notification to distribute edit-locks would be easier to maintain, setup and may have lower latency, but lacks interoperability.

The intention is to minimize DokuWiki changes, and also keep the DokuWiki plugins rather simple. re-use existing frameworks and protocols.

Ideas

The preferred mechanism would be to implement Jabber XMPP Publish-Subscribe extension in conjunction with a XMPP → RPC gatewaty.

Having DokuWiki publish news is a minor task; email-subscription is already possible. Formatting it in XML or Atom and signing the change is straight-forward; wrapping and sending it to a gateway also easy.

Acting upon subscriptions is a bit trickier. It's feasible to just generate an automatic edit request via HTTP-POST for each incoming XMPP news. This could be built-in or happen at a gateway; with design depending on implementation: Authentication could happen internally (DokuWiki signs data-changeset), as part of the protocol (oAuth) or via transport (HTTPS). the choice depends on the use-case and application: user-administrated vs. admin-maintained or low-traffic-decentraliced-wiki vs. mirror/load-balancing.

options:

DokuWiki could use OAuth for setUID-requests - normal do=save POST can be used to perform updates. (oAuth-tokens are tunneled with XMPP-message/request to any gateway - openID can be used as remote user-account)
whitelist/blacklist approach: local xmpp gateway filters and performs wiki updates (write files or hardcoded-auth POST)
custom DokuWiki shared-Auth mechanism. (eg. content-signature)

(1) is the most flexible and cool, alas also the most complex choice. (2) is pragmatic and probably fast (good performance and short implementation-time) wheres (3) may offer more advanced SPAM protection, user configuration and mapping and as well be on the way to provide a lock mechanism.

PubSub does not strictly address locking. However Publishing is an atomic transaction in XMPP so a solution would be to publish an “invalidated” version of a page when beginning to edit and re-publish afterwards. It would either require very short draft-timeout times or DokuWiki would need send AJAX requests on cancel edit and re-publish.

A different approach for handling subscriptions would be a standalone gateway that interfaces with DokuWiki over XML-RPC instead of being implemented as as DokuWiki plugin..

Resources

wokkel implements a HTTP ↔ XMPP gatway that distributing Atom feeds along with an authoritative resource URI. It's intended to run on a host reachable by the web-server (localhost, or in DMZ); the XMPP port is open to public (it's a jabber server) while the HTTP has a whitelist IP filter.

see http://idavoll.ik.nu/wiki/HTTP_Interface and http://idavoll.ik.nu/wiki/HTTP_Interface_Subscription After publication the XMPP-node ID should be included in the xhtml header to provide subscription discovery.

as for DokuWiki clustering:

¹⁾ hardcoded prefix - during development,

Abc midi tutorial

rgareus — 2012-02-19T14:07:39+00:00

This page is based on

Introduction

Abc notation is a simple but powerful ASCII musical notation format, by Chris Walshaw. A tune notated in abc can be played directly from the notation, or many software packages exist which can convert abc notation into MIDI, produce sheet music, play the file through the computer speaker, etc.

Wiki Syntax

This wiki allows to render Abc notation to images and midi files. In order to do so, you need to insert an <abc> command in the wiki page, followed by a unique midi file name X:. The code is parsed by Abc midi until the end tag</abc>, and (if no errors occured) displayed as a png image linked to the midi file.

<abc>
X:42
T:Paddy O'Rafferty
C:Trad.
M:6/8
K:D
dff cee|def gfe|dff cee|dfe dBA|dff cee|def gfe|faf gfe|1 dfe dBA:|2 dfe dcB||
~A3 B3|gfe fdB|AFA B2c|dfe dcB|~A3 ~B3|efe efg|faf gfe|1 dfe dcB:|2 dfe dBA||
fAA eAA|def gfe|fAA eAA|dfe dBA|fAA eAA|def gfe|faf gfe|dfe dBA:|
</abc>

X:42 : this is a unique id for this midi snipplet. if you choose a non unique id, it may be overwritten by other wiki pages
T: (optional): Title of the Tune
C: (optional): Composer
M: (optional): Metrum (eg. M:3/4)
K: : Key (eg. K:F → F-major / F-Dur : one b)

the rest is Abc notation described in the following part of this tutorial.

Abc Syntax

Let's get right into it…

Notes

Middle C is notated as C.

Starting at middle C, the notes in that octave are shown as CDEFGAB.

The next octave above is shown in lowercase. Octaves further above are appended with a '. The middle C can be lowered an octave by appending an ,.

The middle four octaves are written as C,D,E,F,G,A,B,CDEFGABcdefgabc'd'e'f'g'a'b', but note that the range can be extended further by adding more commas or apostrophes. A picture paints a thousand words:

X:44
M:4/8
K:C
C,D,E,F,G,A,B,CDEFGABcdefgabc'd'e'f'g'a'b'

Note length / Timing

Abc allows you to set the ‘default note length’ for each tune. This is set (as a fraction) in the tune header in the L: field.

Default note length	‘English’ terminology	‘American’ terminology
1/2	Minim	Half note
1/4	Crotchet	Quarter note
1/8	Quaver	Eighth note
1/16	Semi-quaver	Sixteenth note

To modify a note length from the default, simply append an integer multiplier to it: with L:1/8 (eight or quaver default) cd2e4 | f/2 g/4 f/4 renders as

X:45
L:1/8
K:C
M:
cd2e4 | f/2 g/4 f/4

Rests

Rests are indicated by the (lower case) letter z. The length of rest is set exactly the same way as the length of note is, eg z4.

Sharps, flats

To sharpen a note precede it with the circumflex or caret ^ ^c

To flatten a note precede it with an underscore _ _B

Double sharps are shown as ^^ and double flats as __

To naturalise (?) a note precede it with an equals sign = eg. =c

Key

The key signature is specified by the K: field eg K:G.

Major keys are assumed, but can be specified by maj eg K:Gmaj.

Minor keys are shown by m or min, eg K:Gm or K:Gmin.

In the key signature field sharps are noted by the hash character # and flats by the letter b, eg

B flat	K:Bb
C sharp	K:C#

Modal keys (the Lydian, Ionian, Mixolydian, Dorian, Aeolian, Phrygian and Locrian modes) can all be specified by adding the first 3 letters of the mode eg K: G mix or K:Gmix

Time signatures

the M: field and the rhythm R: field.

Time signatures, or meters, like default note lengths, are shown as fractions in the M: field, eg: M:6/8 or M:4/4 or M:3/4, and so forth. Common time is shown as C, and cut time as C| (the letter C followed by the pipe symbol).

Abc also includes a rhythm field, R:, which is used for cataloguing and sorting collections of abc tunes: this is entirely free text (although there are obvious ‘standard’ entries eg R:reel, R:jig, R:schottische).

An M: field can be placed in the middle of a tune to denote a change of meter.

Mid-tune changes of key, time etc.

The L: note length field, the M: meter field, the K: key signature field and the Q: tempo field can all be inserted in the middle of a tune to indicate a key change. Strictly speaking this should be on a new line eg to play a G major scale ‘up’ and a G minor scale ‘down’ again,

K:G GABcdefg K:Gm gfedcBAG

but most software packages will allow the use of [ ] square brackets eg

K:G GABcdefg [K:Gm] gfedcBAG.

If you want to change two fields at once, either put them on two new lines like this -

K:G GABcdefg | M:6/8 K:Gm gfe dcB | AGB FED |

or put them both in the square brackets in the middle of the line like so :

K:G GABcdefg | [M:6/8 K:Gm] gfe dcB | AGB FED |

X:46
K:G 
GABcdefg | [M:6/8 K:Gm] gfe dcB | AGB FED |

Barlines and spaces

Barlines are denoted by the pipe symbol |. Our G major scale in jig time immediately becomes more readable :

M:6/8 L:1/8 R:Jig K:G GABcde|fgfedc|BAG

X:48
M:6/8
L:1/8
R:Jig
K:G
GABcde|fgfedc|BAG

A double bar is shown by ||, and by using the square bracket symbol as |] (thin-thick) and [| (thick-thin). Repeats are dealt with soon.

To make the notation even more readable spaces can be inserted to separate groups of notes :

M:6/8 L:1/8 R:Jig K:Gm GAB cde|fgf edc|BAG

Spaces are also used within the melody, and by the various software packages which convert abc into standard notation, to group notes. The spacing of abc notation will tend to mirror the grouping which would be used in standard notation. Spaces may also be inserted at the start and / or end of bars to make the abc more readable. As an example, I find something like

easier on the eye than

Repeats

Repeats bring the colon : into action. The start of a repeated section is shown by |: and the end of a repeated section by :|

Where the end of one repeated section, and the beginning of the next, coincide, :||: is technically correct, but this is usually shown without the pipe symbols eg ::.

Numbered and alternate repeats are indicated by [1 and [2 (etc.). Where the start of a section coincides with a barline the [ symbol may be omitted, eg DE FF |[1 GA Bc :|[2 GA BG || can also be written as DE FF |1 GA Bc :|2 GA BG ||

However if a repeat section does not coincide with a barline, always use the [ symbol instead of inserting an extra | .

Note that there can be no blank space between the barline and the number - eg [1 and |1 are acceptable, whereas [ 1 and | 1 are not.

title (T:) and index (X:)

Nearly every tune has a title, and one should always be included for identification purposes in tune lists, even if the exact title is not known. The title is indicated by the T: field eg T:Ballydesmond polka.

A tune may have more than one title - in this case just add a second, third, etc. T: field (each on a new line) and enter the alternative title(s) in there.

There is one more field to introduce at this stage : the X: index field.

The X: field is primarily for computers' benefit, as they (computers) have much more trouble than human beings in telling where one tune stops and the next starts. Many software packages therefore rely on the X: field to signify the start of a tune, even if there's only one tune in a file, and a blank line, followed by an X: field, delimits one tune from the next. It is therefore good practise to include an X: field at the head of your Abc tune(s).

The X: field is put on the first line of the notation of a tune, and takes the form X:<number>

It is good practise (but not absolutely essential) for the X: field to be incremental, eg the first tune in a file is X:1, the second tune in the file is X:2, etc.

tempo (Q:)

The tempo of a tune is shown in the Q: field, giving either the human or software musician a speed indication, eg Q:120 indicates the tempo as 120 notes of the default note length per minute.

Q:1/8 = 120 can also be used, to specify in this example that the tune goes at the rate of 120 1/8 notes per minute, regardless of the default note length.

A T: field can be placed in the middle of a tune to denote a change of tempo - see the Mid-tune changes selection above.

Elements in the tune body

Ornaments

The general symbol for an ornament is the tilde ~.

The symbol is placed before the note to be ornamented, eg ~G2.

Note that the tilde is a general mark to indicated the presence of an ornament, and does not specify a particular ornamentation - it is usually interpreted as a roll or a turn. For the more precise notation of ornamentation such as Great Highland Bagpipe music, and for the notation of particular grace notes, enclose the notes in curly brackets { } eg {GAGDG}G2.

The notes within curly brackets have no fixed time value, so their length cannot be modified by use of the usual symbols : in other words anything like {G2AG2D}, {GA/G/D/G}, or {GA>GD>G} is out of the question. The pitch of the notes is notated in the usual way, eg the octave modifiers, and ' are useable.

Slurs and Ties

The minus sign - should be used to tie two notes of equal pitch, whilst the round brackets () join two or more notes which are to be slurred, or played legato.

Two notes can be tied together with a minus sign - . This can be applied both within a bar and across bar lines, eg |DEF-|FGA| and |DEF-FGA| are both correct. The tie marking should be placed immediately after a note, but can be followed by a space.

To slur a group of notes or join them together as a phrase , use round brackets ( ) to enclose the grouped notes, eg (DEF|GAB).

Spaces can be used within the slur to improve the legibility of the file. However the first and last notes, (including any pitch and/or length markings) should be placed hard up against the beginning and ending brackets. So (^G A B/c/|E4 D4) is correct, but ( ^G A B/c/|E4 D4 ) is well wide of the mark.

It's also worth mentioning that you can 'nest' slurs inside each other, so that a passage of music finishing with a tied note can be shown either as (D E F (G | G4)) or (D E F G-| G4) are both understood.

Triplets, quadruplets, et al

The basic notation for duplets, triplets, quadruplets etc. is straightforward : an opening round bracket, the number, and the notes within the tuplet eg

Duplet	(2GA
Triplet	(3GAB
Quadruplet	(4GABA

and so on, up to (9GABcdcBAG

Note that there are no spaces in the tuplet.

The values of the particular tuplets are (to quote the abc specification)

(2	2 notes in the time of 3
(3	3 notes in the time of 2
(4	4 notes in the time of 3
(5	5 notes in the time of n
(6	6 notes in the time of 2
(7	7 notes in the time of n
(8	8 notes in the time of 3
(9	9 notes in the time of n

n is 3 in compound time signatures (3/4, 3/8, 9/8 etc), and 2 in simple time signatures (C, 4/4, 2/4 etc.)

Details

For more complicated notation of irregular rhythmic episodes, abc allows for the use of the form (p:q:r

p = the number of notes to be put into time q
q = the time that p notes will be played in
r = the number of notes to continue to do this action for.

If q is not specified, it defaults to 3 in compound time signatures and 2 in simple time signatures. If r is not specified, it is taken to be the same as p.

This comes into play when notating notes of different lengths within a tuplet eg (3:2:2G4c2 or (3:2:4G2A2Bc and explains exactly what is going on in situations such as (3D2E2F2 - which is the same as putting (3:2:3D2E2F2

Chords and Unisons

Chords for guitars etc. can be found here.

Chords within a melody, eg what classical Western notation would show as multiple note heads on a single stem, are shown in abc by enclosing the notes in square brackets [ ]. There should be no spaces within the chord, length and pitch modifiers can be included as required, and it is a convention to state the notes of the chord in ascending order, eg [Acea].

Chords can be arranged to form beamed groups using spaces in the same way that individual notes are, eg [GB][Ac] [B2d2] | [Bd][Ac] [G2B2] | [A4c4e4a4]

X:49
M:4/4
L:1/4
K:C
[GB][Ac] [B2d2] | [Bd][Ac] [G2B2] | [A4c4e4a4]

The syntax for chords can be used to notate more than one part in a single line of music - and in that case, or in cases where two strings play the same note, it will occasionally be necessary to notate a unison (eg both parts playing a note of the same pitch and length). Software which generates classical Western notation from abc will show unisons eg [AA] as a note with both an upwards and a downwards stem.

Guitar chords

Chords for accompanying instruments can be shown in abc using double quotation marks ” ” eg “Dm7”

The chord should appear before the first note of the section of melody which the chord applies to, eg “G”GB d2 | “D”DF A2

X:51
M:4/4
L:1/4
K:G
"G"GB d2 | "D"DF A2

Chords take the format note accidental type / bass

note :	A to G
accidental :	# or b
type :	m, min, maj, sus, dim, +, 7, 9, 11,#5, etc. etc
/ bass :	Bass note
accidental, type, and / bass are all optional.

You may occasionally come across an abc file which uses the older abc style of denoting guitar chords, by surrounding them with addition signs +Gm+ : more recent versions of the abc specification specify the use of the “Gm” style, so please do your chords like that.

Fiddle bowing marks

Up-bow and down-bow marks for fiddlers can be indicated by the letters u (up-bow) and v (down-bow), eg v_Au=Bv^c.

Line ends and line breaks

In software which generates standard Western notation from abc, the general rule is that one line of abc will generate one line of tadpoles-hanging-on-five-barred-gates.

Most packages will however 'wrap' the staff of music onto the next line if your printed page width isn't big enough.

To try to insist that two lines of abc notation make one line of tadpoles, put a back slash \ at the end of the first line. Again, this may be over-ridden by the software if you run out of space.

The other common symbol often seen used in marking line breaks is an exclamation mark ! placed at the end of a line of abc, to force the software generating the standard Western notation to start a new line. This is specific to one particular piece of abc software and is not actually a formal part of the abc notation specification, but (as so many abc files are generated in this particular software package, ABC2Win) it is worth mentioning here.

Accents

If you want to indicate that a particular note should be played staccato, place a dot . before the note, eg .A or even .G.A._B.c .d2.e.d.^c

Song words

The W: field (upper case W) in the header can be used as many times as needed to record the entire words of the song as a block of text eg

W:How much is that doggie in the window
W:The one with the waggly tail?
W:How much is that doggie in the window
W:I do hope that doggie's for sale
(etc. etc.)

This form of notating the song words will produce the words as a single text block below the tune, if the abc file is fed into a software package which generates standard Western notation.

Information fields in the tune header

As seen in the first part of this tutorial, the tune header contains a number of fields giving information about the tune such as title, rhythm, key signature, etc. The introductory tutorial mentioned the fields which must be shown in the tune header, and also described some of the optional information fields which are most commonly used.

The abc specification allows for many more optional descriptive or information fields to be used in the tune header - the full list is :

A:	(Geographical) Area : eg A:Brittany or A:Sussex
B:	Book, eg B:Encyclopeadia Blowzabellica or B:O'Neill's
C:	Composer eg C:Andy Cutting or C:Trad
D:	Discography eg D:New Victory Band, One More Dance And Then
F:	File Name eg http://www.lesession.co.uk/woodenflute.abc
G:	Group eg G:Flute - this is used for the purpose of indexing tunes in software, NOT for naming the group / band you acquired the tune from (which should be recorded in the S: source field).
H:	History - Multiple H: fields may be used as needed to record text about the history of the tune. (Many people (including me) seem to tend to forget about the H: field and instead always put information like that in the N: notes field instead.)
I:	Information - used by certain software packages, NOT for historical information or notes (which should be recorded in the H: or N: fields).
K:	Key -see part one of this tutorial for further details
L:	Default note length -see part one of this tutorial for further details
M:	Meter :see part one of this tutorial for further details
N:	Notes : Multiple N: fields can be used as needed to record detailed text notes about, well, just about anything you want to say about the tune that won't go in any of the other fields really …
O:	(Geographical) Origin : eg O:Irish or O:Swedish
P:	Parts -see below for further details
Q:	Tempo -see part one of this tutorial for further details
R:	Rhythm -see part one of this tutorial for further details
S:	Source - where you got the tune from eg S:Olio or S:Dave Praties
T:	Title -see part one of this tutorial for further details
W:	Words -see below for further details
X:	Tune reference number -see part one of this tutorial for further details
Z:	Transcription note - the identity of the transcriber or the source of the transcription, eg Z:Steve Mansfield

To repeat a small part of the first part of this tutorial:

The X: index, T: title, M: meter, L: default note length, and K: key field are obligatory : the others are optional.

The fields usually occur in the following order:

X:
T:
M:
L:
[optional fields]
K:

And immediately following the K: field on the next line is the body of the tune, eg the representation of the notes of the melody.

Putting it all together

Example Source

X:1
T:Plead for Slough
T:Speed The Plough (arr.)
M:4/4
L:1/8
H:Illustrative file for abc tutorial
F:http://www.lesession.co.uk/abc/abc_notation_part2.htm
N:The tune that should be the English national anthem,
N:renamed in this version in honour of the John Betjeman poem
C:Trad.arr. Steve Mansfield June 2000
R:reel
P:(2A2B)ad infinitum
Z:Steve Mansfield 6/6/2000
K:G
P:A
"G" (GAB)c dedB | "G" .d.e.d.B dedB |
"Am" c2ec "D7" B2dB | "D"A2"Dm"A2 "Am" A2BA |
"G" (GABc d)edB | "G" .d.e.d.B dedB | "C" ~c2ec "G" ~B2dB- |
"D7" BA A2 "G" ~G4 ::
P:B
"C" g2g2 {GABcdef}g4 | "G" g2fe dBGB |
"Am" cAEc "Bm"BGDB | "F#m"A2A2 "D"A4 |
"C"g2g2 "G"g4 | "G"g2fe dBGB |
"C" (5cdedc "Am" ec"Bm"B2"~G"dB |
"A"[A2c2]"Am"[A2a2] "G"[G4B4d4g4] :|

Example

X:50
T:Plead for Slough
T:Speed The Plough (arr.)
M:4/4
L:1/8
H:Illustrative file for abc tutorial
F:http://www.lesession.co.uk/abc/abc_notation_part2.htm
N:The tune that should be the English national anthem,
N:renamed in this version in honour of the John Betjeman poem
C:Trad.arr. Steve Mansfield June 2000
R:reel
P:(2A2B)ad infinitum
Z:Steve Mansfield 6/6/2000
K:G
P:A
"G" (GAB)c dedB | "G" .d.e.d.B dedB |
"Am" c2ec "D7" B2dB | "D"A2"Dm"A2 "Am" A2BA |
"G" (GABc d)edB | "G" .d.e.d.B dedB | "C" ~c2ec "G" ~B2dB- |
"D7" BA A2 "G" ~G4 ::
P:B
"C" g2g2 {GABcdef}g4 | "G" g2fe dBGB |
"Am" cAEc "Bm"BGDB | "F#m"A2A2 "D"A4 |
"C"g2g2 "G"g4 | "G"g2fe dBGB |
"C" (5cdedc "Am" ec"Bm"B2"~G"dB |
"A"[A2c2]"Am"[A2a2] "G"[G4B4d4g4] :|

tatort-dl - an ARD-mediathek download utility

rgareus — 2012-02-19T13:12:06+00:00

tatort-dl is a shell-scripted CLI tool for downloading films from http://www.ardmediathek.de/.

It's named after it's main purpose: to download Tatorts ;) However - as of Jan 25 2010 - it also works with any other content on http://www.ardmediathek.de/.

Please read the license under “help” at ardmediathek.de before using tatort-dl. Some Films or Clips are only available during certain hours and/or time-periods.

Installation and Usage

tatort-dl will work on all systems supporting bash, curl and rtmpdump. It's developed for GNU/Linux and may work on OSX and BSD.

Download: tatort-dl.sh (latest).

Save it as tatort-dl in ~/bin or /usr/local/bin/ and mark it as executable chmod +x tatort-dl.

You need to have rtmpdump and curl software installed (sudo apt-get install rtmpdump curl).

Usage:
  tatort-dl <ARDmediathek-URL> [out-file]
The default out-file name is ./format<ard-uid>.f4v
 
Example:
  tatort-dl "http://www.ardmediathek.de/ard/servlet/content/3517136?documentId=3701294"

Source Code

view tatort-dl.sh source

#!/bin/bash
URL=$(echo -e "$1" | grep "^http")
OUTFILE=$2

INTERACTIVE=yes
RTMPDUMP=rtmpdump
RTMPDUMPOPTS=""
#RTMPDUMPOPTS+=" --live"
#RTMPDUMPOPTS+=" --resume"
#RTMPDUMPOPTS+=" --quiet"

if test -z "$URL" ; then
  echo -e "Error: missing or invalid parameters\n\nUsage:\n $0 <ARDmediathek-URL> [out-file]\nThe deafult out-file name is ./format<ard-uid>.f4v\n\nExample:\n $0 \"http://www.ardmediathek.de/ard/servlet/content/3517136?documentId=3701294\"\n" >&2;
  exit 1
fi

echo -en "curl \"$URL\" .."
RTMPURLS=$(curl -s "$URL" | grep -i rtmp)


if test -z "$RTMPURLS" ; then
  echo  -e "\nError: no 'rtmp://' URLs were found on the given Page.\n"
  exit 1;
fi

COUNT=$(echo -e "$RTMPURLS" | wc -l)
  echo -e " ..found $COUNT RTMP URL(s)."

urldecode(){
  echo -e "$(sed 'y/+/ /; s/%/\\x/g')"
}

FLASH=$(echo "$RTMPURLS" | grep flashvars | tail -n1)
if test -n "$FLASH"; then

  RTMPURL=$(echo -ne "$FLASH" \
            | sed 's/^.*streamer=\([^&]*\)&.*$/\1/g' \
            | urldecode)
  PLAYPATH=$(echo -ne "$FLASH" \
             | sed 's/^.*file=\([^&]*\)&.*$/\1/g' \
             | urldecode)
  #echo "RTMP: $RTMPURL"
  #echo "FILE: $PLAYPATH"

else

  # try high-qualty first
  PARAM=$(echo "$RTMPURLS" | grep Web-L)
  # fall-back to medium-qualty
  if test -z "$PARAM"; then
    PARAM=$(echo "$RTMPURLS" | grep Web-M)
  fi
  # 2nd fall-back: use any rtmp URL
  if test -z "$PARAM"; then
    PARAM=$(echo "$RTMPURLS" | tail -n 1 )
  fi

  RTMPURL=$(echo -ne "$PARAM" | sed 's/^.*"\(rtmp[t]*:[^"]*\)",.*$/\1/g')
  PLAYPATH=$(echo -ne "$PARAM" | sed 's/^.*"\(mp4:[^"]*\)").*$/\1/g')
fi

test -z "$RTMPURL" && RTMPURL="rtmp://vod.daserste.de/ardfs/"

if test -z "$OUTFILE"; then
  OUTFILE=$(echo -ne "$PLAYPATH" | sed 's/^mp4:.*\/\([^\/?]*\)\?.*$/\1/g')
  OUTFILE=$(echo -ne "$OUTFILE" \
            | sed 's/^.*\///g' \
            | sed 's/\?.*$//g' \
            | sed 's/mp4://g' \
            | sed 's/\.f4v$//' \
            | sed 's/\.flv$//'\
           )
  OUTFILE="${OUTFILE}.flv"
fi

echo
echo "Parameters:"
echo " RTMP-URL : $RTMPURL"
echo " Playpath : $PLAYPATH"
echo " Saving to: $OUTFILE"
echo -n " PWD      : "
pwd
echo

if test -z "$PLAYPATH -o -z "$OUTFILE ; then
 echo "Error: empty playpath or blank output filename."
 exit 1
fi

if test -e "$OUTFILE"; then
  echo "WARNING: output file "$OUTFILE" exists."
  if test -n "$INTERACTIVE"; then
    echo -n "[A]bort/[d]elete it/[r]esume? [A/d/r]? "
    read -n 1 VAL
    echo
    if test "$VAL" == "d"; then
      rm -i "$OUTFILE";
    elif test "$VAL" == "r"; then
      RTMPDUMPOPTS+=" --resume"
    else
      exit;
    fi
  else # NON-INTERACTIVE
    echo "Error: file exists. bailing out."
    exit
  fi
fi

if test -n "$INTERACTIVE"; then
  echo "rtmpdump command-line:"
  echo " #$RTMPDUMP $RTMPDUMPOPTS -o \"$OUTFILE\" --playpath \"$PLAYPATH\" -r $RTMPURL"
  echo

  echo -n " Start Download ? [Y/n] "
  read -n 1 VAL
  echo
  if test "$VAL" == "n" -o "$VAL" == "N";  then
    exit;
  fi
fi

$RTMPDUMP $RTMPDUMPOPTS -o "$OUTFILE" --playpath "$PLAYPATH" -r $RTMPURL

echo
ls -l "$OUTFILE"

floss, video