Gebruik Capimonitor

Hallo allemaal,

Ik gebuik al jaren capimonitor met een oude versie van de CD foon gids.
Ik heb onlangs een andere versie gekregen (versie=ZM2.2004) en heb deze met succes gedumpt.
Met Megafoonversie 2.04 kan ik ook goed zoeken.
Het probleem is dat ik capimonitor niet werkend krijg om in de database te zoeken.
Ik heb nu foongrep Versie=2.9a geinstalleerd.

Ik heb al een tijd op het forum gezocht maar kan nog geen duidelijke handleiding vinden hoe ik e.e.a. in moet stellen.

Ik hoop dat iemand mij hiermee kan helpen.

Hoi japio,

Ik heb wel een programmatje voor de laatste foondump formaat gemaakt. Germ werkt er m.i. ook mee. Dus privat mail naar germ lijkt mij handig begin om het werkend te krijgen…

De vriendelijke groet Jan Marco

Het ligt niet zozeer aan Capimonitor als wel aan Foongrep, die kan niets met de nieuwere foongids-CD’s. En jammer genoeg is de manier waarop Capimonitor de hulp inroept van Foongrep “hardgebakken” in “Capimonitor.exe” zelf. Dat maakt het lastiger om een alternatief voor Foongrep te verzinnen dat wel werkt met de latere versies van de CD-foongids. We hebben het met z’n allen ooit een keer opgelost in dit forum maar die tekst is naderhand verloren gegaan in een crash. Een van de forumbezoekers heeft destijds een “namaak-foongrep” geschreven maar die kan alleen in een gedumpte Foongids zoeken als die in een mysql-database is gezet.

Dat is sowieso een belangrijk verschil tussen de werking van Foongrep en de latere Foondumpers. Foongrep zocht daadwerkelijk op de originele CD-foongids naar wie er bij een telefoonnummer hoorde, het tegenwoordige ‘dumpen’ bestaat daaruit dat je eenmalig de hele inhoud “overneemt” op je harde schijf en vervolgens steeds daarin laat zoeken. Gegevens van de CD-foongids komen in eerste instantie aan als tekst waarin naam- en adresonderdelen uit elkaar worden gehouden met stokjes, “|”. Die tekstbestanden kan je zo laten of met een van de scripts die met Foondump meekomen importeren in een database naar keuze.

Wat jij zoekt als je Capimonitor met nieuwere CD-foongids-bestanden wil laten werken is een mini-programmaatje met de volgende eigenschappen:

  • het moet "Foongrep.exe" heten maar het hoeft geen echte Foongrep te zijn
  • het is van de 'command-line' te starten
  • er kunnen op het moment van starten "opdracht-parameters" aan meegegeven worden, dwz. het telefoonnummer dat Capimonitor via de Capi van de "binnenkomende oproep" heeft geplukt
  • het moet of zelf of via weer andere software kunnen zoeken in het tekstbestand waarin Foondump de telefoongids geparkeerd heeft of in de database waar dat bestand eventueel in overgeheveld is
  • het zoekresultaat kan alleen aan Capimonitor overgedragen worden via een tijdelijk bestandje dat "capimon.log" genoemd moet worden
  • voordat je het aan Capimonitor overdraagt moet het zoekresultaat terugvertaald worden naar het formaat van de CD-foongids waar Foongrep destijds nog wel mee werkte, dwz. de volgorde van naam, adres en telefoonnummer en het letterteken dat ze uit elkaar houdt moet overeenkomen
Wat een lastpak, die Capimonitor! Maar goed, als je denkt dat je kans ziet om jouw CD-foongids in MySql te importeren dan zou je hier in het forum even moeten vragen naar het hoe en wat van die Foongrep-vervanger. Als je het bij het genoemde tekstbestand wil laten (vaak ook "csv"-bestand genoemd) dan zou ik kunnen kijken of het niet via-via opgelost kan worden, bijvoorbeeld met het "findstr.exe" dat op iedere Windows-PC te vinden is. De zoekopdracht "[i]findstr «telefoonnummer» white_subscriber.txt > capimon.log[/i]" komt al in de buurt van wat Capimonitor van Foongrep verwacht.

Alternatief is natuurlijk een ander ‘caller-id’-programmaatje zoeken met een interface die eventueel wel eenvoudig op het spoor van een Foondump gezet kan worden.

Iemand die zelf een programmaatje kan schrijven kan ook kijken naar een tweedehands ISDN Lanmodem
http://koopjes.marktplaats.nl/computer_hardware/modems_isdn_en_faxen/12134364.html?return=eJwtykEKwjAQQNG7FNpl4iS6mVBEbxJqISFpMzQDrYp3d4Ku%2Flt8j4DviCdXEewFuzr7bQouMBNqnQrNq1r8lpiy91zVmvVvURToeuQRhkcd097bm53K0ts7FzEIMgtekRoPYevzX2i%2FMY2m0Z6FpUaxGWiEzn2%2B8%2FwuQQ%3D%3D&df=1
. Dat ding ‘broadcast’ inkomende telefoonnummers over het netwerk waar het op aangesloten is. Er zat altijd al software bij dat alleen het telefoonnummer liet zien maar die pakketjes zijn eenvoudig te decoderen en te vertalen naar een zoekopdracht die vervolgens naam en toenaam van de beller(s) ultramodern in een ‘systemtray-balloon’ laat verschijnen, etc.

Het programma waar weerman naar refereert bestaat reeds en is geshreven door Jan Marco.
Het is de koppeling tussen de mysql database welke je genereert door via foondump de cdfoongids te dumpen naar een mysql database en capimonitor.
Gebruik momenteel de versie 0.11 met Cdfoon van 4-2005

Gebruik het zelf al meer dan een jaar en capimonitor werkt er perfect mee. Enigste probleem is dat capimonitor de plaats van foongrep.exe niet onthoudt zodat je elke keer als de comuter opnieue is opgestart
Wanneer je mij een pm stuurt kan ik het naar je mailen.

Daarnaast weet ik dat rgj eraan werkt(e) om Moony, een vergelijkbaar programma als capimonitor aan de praat te krijgen met foondump. Weet alleen niet hoever hij hier mee is.

Iets genuanceerder: we hebben diverse pogingen gedaan om de maker van Capimonitor te bewegen om - op veler verzoek - goede ondersteuning voor Foondump-databases in te bouwen. Dit heeft tot niets geleid.

Foongrep (of de makers ervan) kunnen het niet helpen. Die zijn al lang geleden gestopt.

Een eind. Maar ik heb ook de laatste maanden niet echt veel hobby-tijd gehad. :frowning:
De source zit echter al in de huidige distro en wanneer je de databasegegevens hardcoded en de boel hercompileert zou je een eind moeten kunnen komen.

Met Foongrep zoeken op telefoonnummer was legendarisch compact, alles wat je nodig had: een piepklein stukje software en de originele CD. Niet eerst vooraf alles dumpen, zoiets hebben we sinds Babyfoon niet meer gezien.

Experiment: Foondump leest de met Zlib gecomprimeerde datablokken sequentieel dus achterelkaar in volgorde uit maar je zou eenvoudig naar een willekeurig blok kunnen springen en alleen dat blok laten decomprimeren als je wist welk blok je moet hebben voor een naam en een adres bij een dit geval via caller-id doorgegeven telefoonnummer. De telefoongids staat op naam gesorteerd op de CD en wat de producent ook aan indexen dacht nodig te hebben, een index op de telefoonnummers zit er uiteraard niet bij. Die tabel gaan we dus eerst zelf maken, een lijst van telefoonnummers gekoppeld aan het volgnummer van het ‘zlib’-blok waar het nummer in staat:

telefoonnummer blok 0101502588 4053 0102010044 1173 0102010050 2388 ...
Van elk telefoonnummer is nu bekend in welk blok het zit. Op de laatste CD zijn dat zo’n 6000 blokken. Nog een tabel, daarin van elk blok de startpositie (offset) in het totale bestand:

blok offset 1 0 2 30786 3 51299 ...
Met behulp van deze twee lijsten kan een zoekopdracht voor de gegevens bij een telefoonnummer uitmaken waar in het databestand het moet zijn, dus welk blok het eruit moet pikken:

telefoonnummer offset 0101502588 110113477 0102010044 31938498 0102010050 64801569 ...
Is een blok eenmaal binnengehaald en ontzlibt dan is daarna ook een nummer snel gevonden, een blok bevat tussen de 300 en 1100 vermeldingen, afhankelijk van de lengte van die vermeldingen. Bij het produceren van de CD wordt kennelijk steeds met een nieuw blok gestart als de vorige volgelopen is dwz. telkens als de omvang van het plukje te comprimeren vermeldingen een goed hanteerbare 65KB naderde.

En dat blijkt te werken, personalia die horen bij een (gesimuleerde) binnenkomende oproep komen vlot direct van de CD af. Maar het is een pyrrusoverwinning, de telefoonnummers, de bloknummers en -wijzers beslaan samen met hun indexen bij elkaar nog steeds een kleine 300MB, lookuptabellen voor straat-, plaatsnamen en rubrieken inbegrepen. Dat lijkt nog niet op dat broodmagere Foongrepje waar we naar op zoek zijn.

Nog een poging: bij het maken van die telefoonnummer-hulptabel zag je dat het wel meeviel met de tijd die het kostte om alle blokken te doorlopen EN te decomprimeren want nu is dat zonder de gebruikelijke overhead van ook alle velden decoderen en wegschrijven. Kan je dan niet gewoon blindelings alle blokken voorbij laten komen en kijken in welk blok het gezochte telefoonnummer staat?

Als test dan eerst maar eens zoeken naar een telefoonnummer helemaal aan het andere eind van de telefoongids, dus het nummer van iemand wiens naam met een “Z” begint of anders nog verder in het niemandsland daarachter, bijvoorbeeld “èLVé/Labor Vincit”: 0715134332. Voor zo’n zoekactie kan je het telefoonnummer beter terugbrengen naar het formaat waarin het door C-Content (voor compressie) op de CD gezet is anders moeten alle kandidaten eerst gedecodeerd worden voor je ze kan vergelijken met het nummer waarnaar gezocht wordt. In dit geval ga je het telefoonnummer 0715134332 terugdraaien naar de oorspronkelijke bytes 82 62 45 44 30 eventueel nog met een B2 ervoor, in CDfoon-‘speak’ intern het teken dat er een (BCD-gecodeerd) telefoonnummer volgt… Daar gaat ie dan, de tijd voor deze worst-case, naam en adres horend bij dat telefoonnummer staan dus bijna helemaal aan het eind: 14 seconden.

Ter vergelijking met de originele Foongrep op de 1998 CD zoeken naar een vermelding in de Z van Zwijndrecht: optie -t telefoonnummer, 4 seconden; zoeken op naam en plaats, 0 seconden; met een naam zonder plaats, 24 seconden. Of er in Foongrep voor zoeken op telefoonnummer in werkelijkheid via het netnummer op plaatsnaam gezocht werd, wie zal het zeggen? CD-foons 19XX waren kennelijk op plaatsnaam georganiseerd, laat je dat los dan val je terug op ‘brute-force’ zoeken en kost dat ook in Foongrep meer tijd. Op de huidige CD-foongids zal daarentegen zoeken op naam weer sneller zijn. Immers, je kan dan “extrapoleren”, dus voorspellen in welk blok het beste met zoeken begonnen kan worden omdat de hele telefoongids op naam gesorteerd is.

Met het door Jan Marco geschreven “tussenprogramma’”, foondump naar mysql en capimonitor is het nu ook weer gelukt om eea draaiend te krijgen met de 2007 cd foon.

Wel zag ik dat www.capimonitor.nl niet meer bestaat en dat capimonitor derhalve niet meer te downloaden is.

Het wordt dus langzaam aan tijd om eens naar een alternatief te gaan kijken. Tapirex is een mogelijkheid, vooral met de koppeling naar www.gebeld.nl Echter, het is niet dusdanig aan te passen zoals capimonitor wel is.
Moony is ook een alternatief, al krijg ik hier helaas geen callerid gegevens terug uit de database.

Ik weet dat rgj ermee bezig is (geweest) om een alternatief voor capimonitor te ontwikkelen. Aangezien eea toch regelmatig in het forum terugkomt is het misschien iets om weer in de “spotlight” te zetten en, samen met anderen, verder te gaan ontwikkelen.

Uiteraard zijn andere alternatieven zeer welkom.

Germ

Is dat wat? Opgehaald. Geinstalleerd. Doet het. Met z’n zelf meegebrachte “Contact”-database (Access) of met de “TRexLookUpNLWeb.dll” - wat Germ zei - die gaat voor een nummer naar gebeld.nl en komt dan eventueel met een naam terug.

Via ODBC laten ruiken aan Foondump in Access. Aan Foondump in MySQL. Zal wel aan mij liggen, werkt allebei niet.

Kan voor een lookup nog uitwijken naar een zelfgemaakte ‘Plugin’. Samplecode voor een VB-dll wordt meegeleverd:

    [b]..\TapiRex\TapiRex SDK\LookupNamePlugins\TRexLookupExample[/b]
Die zijn belangrijkste taak bestaat uit: [code]Function Plugin_ReverseLookup(ByRef sNumber As String, _ sName As String, _ sImage As String, _ sExtra As String) As Boolean[/code] Die aangepast voor een lookup met DAO in een Access-dump: [code]With OpenDatabase("foondump.mdb") Plugin_ReverseLookup = False With .OpenRecordset("SELECT * FROM white_subscriber WHERE phone='" & sNumber & "'") If Not (.BOF = -1 And .EOF = -1) Then sName = Trim$(!lastname & " " & Trim$(!firstname & " " & !infix)) sExtra = Trim$(!streetname & " " & Trim$(!housenumber & " " & Trim$(!postalcode & " " & !city))) sImage = "260x60_1888.gif" Plugin_ReverseLookup = True End If End With End With[/code] In werkelijkheid zullen ze niet via dit nummer uitbellen, ge-popupt met de simulatie-optie van TapiRex:
    [img]http://img440.imageshack.us/img440/5148/tapirex3pk2.gif[/img]
Idem met ADO laten kijken in een 'white_subscriber' die in MySQL staat: [code]With New ADODB.Recordset .Open "SELECT * FROM white_subscriber WHERE phone='" & sNumber & "'", "DSN=Foondump2007" If Not ... ... End If End With[/code]

Foondump. Alleen Access en geen MySQL?

Wel eens afgunstig in “fd05-mysql” gekeken?

Niet zo luxe maar werkt wel - VBScript, dumpt ‘white’ en zet ‘subscriber’ in Access, met speciaal voor zoeken vanuit TapiRex (zie hierboven) een index op kolom ‘phone’:

[code]Set sh = CreateObject(“WScript.Shell”)
path = sh.CurrentDirectory

With CreateObject(“Scripting.FileSystemObject”)
fn = path & "\white_subscriber.txt"
If .FileExists(fn) Then .DeleteFile fn

Wscript.Echo “Start dumpen …”

sh.Run “fd05-csv ““D:\Install\program files\De Telefoongids\CD-foongids\Data”” w”, 1, True

If .FileExists(fn) Then
fn = path & "\foondump.mdb"
If .FileExists(fn) Then .DeleteFile fn

Wscript.Echo "Start importeren in Access ..."

With CreateObject("DAO.DBEngine.36")
  With .CreateDatabase(fn, ";LANGID=0x0409;CP=1252;COUNTRY=0", 64) 'dbLangGeneral, dbVersion40
    .Execute "SELECT * INTO white_subscriber FROM [Text;Database=" & path & "].[white_subscriber.txt]"
    .Execute "CREATE UNIQUE INDEX PK ON white_subscriber (id) WITH PRIMARY"
    .Execute "CREATE INDEX TF ON white_subscriber (phone)"
    .Close
  End With
End With

Wscript.Echo "Klaar"

End If

End With[/code]
Het hele proces leunt zwaar op dit tekstbestandje, noem het (verplicht) “schema.ini”. Moet ook bij “white_subscriber.txt” in dezelfde dir staan:

[white_subscriber.txt] ColNameHeader=False Format=Delimited(|) CharacterSet=ANSI Col1=id long Col2=title char width 40 Col3=firstname char width 128 Col4=infix char width 40 Col5=lastname char width 128 Col6=streetname char width 64 Col7=housenumber char width 24 Col8=postalcode char width 9 Col9=city char width 80 Col10=phone char width 20 Col11=category char width 5