stehe mal wieder kurz vor einem nervenzusammenruch -> serverlog durchsuchen geht nicht!

moin,
ich verstehe es einfach nicht.... ich habe ein 150 bis 3000 MG großes serverlog das ich nach einem string "map:" durchsuche.
ich muss als ergebnis immer den letzten fund immer die zeilennummer haben (nicht die nummer ausm log sondern die reale)
und die suche mit meinem code zeigt mir ergebnisse an ganz anderen stellen:
hier der code:

Local $split, $iii, $line, $count
global $consoleall = FileRead(@TempDir&"\logripped.txt")
Local $aText = StringSplit($consoleall, @LF)
$line = False
For $i = $aText[0]-1 To 0 Step -1
If StringInStr($aText[$i], "map:", 1) Then
$line=$i
ExitLoop
EndIf
Sleep($Speedsetter)
Next

ich bekommte als ergebnis der suche z.B. die folgende line der der textdatei:

[  1590190] Com_TouchMemory: 0 msec. Using sum: 746783988

auch hatte ich als ergebnis schonmal die line wo nur das wort: </info> (oder so ähnlich) stand!

wo steht denn da bitte das wort "map:" ? verflixt ...das macht mich noch verrückt!

ich suche dringend eine resoucenschonende lösung und eine aufklärung

vielen dank liebe community !

Zitat von Xenobiologist

[autoit]

Local $sText = ClipGet()

[/autoit] [autoit][/autoit] [autoit]

StringReplace(StringMid($sText, 1, StringInStr($sText, 'map:', 2, -1)), @CRLF, @CRLF)
MsgBox(0, "", "Gefunden in Zeile " & @extended + 1 & @CRLF)

[/autoit]

danke, aber das GEHT NICHT ....
ich bekomme zwar ein ergebnis, aber das ist nicht die letzte zeile, sondern mitten drinnen
ich habe gerade bemerkt, dass das log doch ne ganze ecke größer werden kann als 3 mb ...

vielen dank an alle bemühten!
ich habe das problem gefunden (hoffe ich)
und zwar war das der zeilenumbruch im weg.

@CR war richtig ... offensichtlich ist das bei hex 0D
für den zeilenumbruch das trennzeichen....

aber falls nicht meld ich mich wieder, wenn ichs überlege